From: "Ronald E. Daniel" <firstname.lastname@example.org> Message-Id: <9507071048.ZM24167@idaknow.acl.lanl.gov> Date: Fri, 7 Jul 1995 10:48:22 -0600 In-Reply-To: Chris Weider <email@example.com> To: Chris Weider <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Subject: Re: Follow up on charter proposal On Jul 7, 10:12am, Chris Weider wrote: > There are three separate components lumped together under the rubric > 'URC'. The first is basic functionality. This is being addressed under > the URC Requirements document, but that functionality will necessarily > evolve as we get deployment experience with URNs and URCs. I agree that our understanding of necessary functionality will evolve. However, I think we already have a pretty good picture of the sorts of things we will want to do with the URC service, and that we are better off getting our deployment experience within a common framework. As primary author of the only current Internet draft proposing a URC specification, I naturally think that framework is where to begin. I think it has the necessary functionality and extensibility. If it doesn't I want to know real soon so that a better scheme can be devised. > There need to > be mechanisms in place to enhance functionality. The central idea behind the draft URC spec is the use of network-accessible attribute set definitions so that we have an extensibility mechanism. In what way does this not meet the need for functionality enhancement? > The second is > transfer syntax or encoding syntax. There seems to be a bit of confusion > between the transfer syntax problems and the basic functionality > questions: these are two facets of the problem which are separable and > should be handled separately, and I believe that the work on URCs should > specifically be laid out to handle these separately. The draft URC spec specifically allows multiple transfer syntaxes and gives examples of how URC info could be conveyed in at least three different syntaxes. Our demo shows how URCs can be encoded using text/html, text/sgml, text/x-urc_a (a slight modification of text/urc0), and text/x-srs (sample rating system - a modification of the default attribute set). After Stockholm we will be looking at digital signatures, etc, and may get into binary transfer syntaxes. The door is open for people to define different transfer syntaxes. In what way does this not meet the need you have identified? > The third is basic > agreements on what 'schema' should be used in URCs. This work is being > done in other fora than the IETF but the IETF should have mechanisms to > bring the work done in and publish it as RFCs. The default attribute set proposed in the draft URC spec is based on the Dublin core, one of the external efforts to which you allude. The notion of named attribute sets allows the use of other schemata, and things like IAFA templates and RFCs 1357/1807 are provided as specific examples in the draft. In what way does this not meet the need you have identified? > All of these threads > are more nebulous and require more time than the URN work; it seems to > me that all Leslie is suggesting is that we do URLs and URNs first > to determine what additional requirements this may impose on the construction > and deployment of URCs. I agree that these things are nebulous and require experimentation. I contend that the draft URC spec was specifically designed to allow just the sort of extensions that you are asking for, and that in the abscence of examples to the contrary, we would be better off doing those experiments inside the same framework. -- Ron Daniel Jr. email: email@example.com Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 tautology: "Conformity is very popular"