Re: Follow up on charter proposal

Ronald E. Daniel (rdaniel@acl.lanl.gov)
Fri, 7 Jul 1995 10:48:22 -0600


From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Message-Id: <9507071048.ZM24167@idaknow.acl.lanl.gov>
Date: Fri, 7 Jul 1995 10:48:22 -0600
In-Reply-To: Chris Weider <clw@bunyip.com>
To: Chris Weider <clw@bunyip.com>, leslie@bunyip.com, terry@ora.com,
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: rdaniel@acl.lanl.gov
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"