Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

Keith, you wrote:

> On October 30-31, several proponents of various URN schemes met to discuss
> ways to make progress on URNs.  This message contains a report of that
> meeting, including a list of items for which there was general agreement,
> a list of topics requiring further discussion, and outlining areas 
> and assignments for additional work. 

I may be missing something, but this wasn't an open invitation meeting, 
right?  For example,you might describe me as an *opponent* of some of 
the proposals.  I certainly didn't know you were having this meeting.

Given this, I think you should make clear what is going on.  Your 
report makes me uncomfortable, because you present it as if the meeting 
generated some kind of consensus of which the recipient mailing lists 
should take part.  Since most of us on the mailing lists weren't given 
the opportunity to present our views, don't you think you might be seen 
as setting up an exclusive club to do the URN work?

> A URN BOF has been scheduled for the Dallas IETF for further discussion 
> of these topics.

This is a Good Thing, although it suggests you aren't reading the 
mailing lists yourself.  Ron announced this yesterday already.

> Agreements:

> 2.  New DNS record type 
> 
>     It is desirable to define one or more new DNS resource record types
>     (tentatively called NAPTR records) that define mappings from 
>     the "NA" portion of a URN to resolution servers for that URN.  
>     The new resource records will allow listing of multiple resolution
>     servers and protocols.
>     
> 3.  Basic resolution strategy:
> 
>     Transform the NA portion of the URN into traditional domain name
>     syntax, and query DNS for any NAPTR records listed under that domain.

Not the DNS limitation again.   Please consider putting some 
extensibility in to the proposal, please please.

>   Service requests
>     Probably two dimensions of service requests:
>      
>       a.) Resource record encoded services
>           may be a core set of such services which can be defined
>           in advance.
>       
>       b.) Document Link service requests
>       
>           there needs to be a way to invoke services by specification
>           within a document.

What have these got to do with URNs?  Leave stuff like this for URC 
services to worry about.  The latter, especially, has already been done 
without URNs and without embedding hard links into documents, even.

________________________________________________________________________
Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779

Received on Wednesday, 8 November 1995 11:03:20 UTC