difficuties with new internet draft (ietf-uri-yaurn-00)

Clifford Lynch <clifford.lynch@ucop.edu> Tue, 21 March 1995 21:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14353; 21 Mar 95 16:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14348; 21 Mar 95 16:37 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa17249; 21 Mar 95 16:37 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19429 for uri-out; Tue, 21 Mar 1995 15:43:34 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19419 for <uri@services.bunyip.com>; Tue, 21 Mar 1995 15:43:31 -0500
Received: from stubbs.ucop.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11100 (mail destined for uri@services.bunyip.com) on Tue, 21 Mar 95 15:43:25 -0500
Received: by stubbs.ucop.edu (5.57/1.34) id AA05130; Tue, 21 Mar 95 12:30:54 -0800
X-Sender: cal@stubbs.ucop.edu
Message-Id: <v02120903ab94e615e778@[128.48.108.83]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 21 Mar 1995 12:44:56 -0800
To: uri@bunyip.com, phoffman@proper.com, rdaniel@lanl.gov
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Clifford Lynch <clifford.lynch@ucop.edu>
Subject: difficuties with new internet draft (ietf-uri-yaurn-00)
X-Orig-Sender: owner-uri@bunyip.com
Precedence: bulk

I've just made a fast pass through this draft which was posted today. I
have a MAJOR problem with this draft from a structural point of view; my
concerns here really go far beyond the specific mechanisms proposed in this
draft document. I believe that this draft should be broken into at least 2
and more probably 3 draft RFCs.

The first should deal ONLY with the syntax of the URN; it should not
address resolution (other than to note that resolution processes will be
needed). The second should deal with the proposal for the DNS URN scheme.
The third should deal with the specific HTTP-based resolution mechanism
proposed for the DNS URN scheme. Arguably, draft RFCs 2 and 3 could be
combined but it would be clearer, I think, if they were not.

I would also raise a few other related points. I think that we need to look
carefully at what in the proposed syntax is really generic URN sytnax and
what is substructure that is specific to the proposed DNS scheme. The
statements in the first paragraph of section 3 on resolving URNs are at
best only applicable to the proposed DNS URN scheme, and actually I think
that it would be more appropriate to characterize them as a description of
the particular resolution method and its properties. Clearly all URNs from
all naming authorities and within all schemes are not going to get resolved
the same ways, and there will be many methods of resolution, I think;
further these methods of resolution will change over time independent of
the syntax of URNs.

Since as I understand it this is on the agenda for the upcoming IETF
meeting,  I would strongly urge the authors to try to separate out the
issues into separate documents; I think that this will lead to a much
better-focused discussion and more rapid progress.


Clifford

Clifford Lynch
University of California
clifford.lynch@ucop.edu