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
- difficuties with new internet draft (ietf-uri-yau… Clifford Lynch
- Re: difficuties with new internet draft (ietf-uri… Ronald E. Daniel
- Re: difficuties with new internet draft (ietf-uri… Ronald E. Daniel