[URN] Re: URI documents

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> Sat, 27 December 1997 07:50 UTC

Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id CAA25324 for urn-ietf-out; Sat, 27 Dec 1997 02:50:54 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id CAA25310 for <urn-ietf@services.bunyip.com>; Sat, 27 Dec 1997 02:50:51 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id CAA10648 for urn-ietf@services; Sat, 27 Dec 1997 02:50:49 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id CAA10637; Sat, 27 Dec 1997 02:50:43 -0500 (EST)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa26429; 26 Dec 97 23:46 PST
To: Leslie Daigle <leslie@bunyip.com>
cc: jcurran@bbn.com, harald.t.alvestrand@uninett.no, moore@cs.utk.edu, masinter@parc.xerox.com, uri@bunyip.com, urn-ietf@bunyip.com
Subject: [URN] Re: URI documents
In-reply-to: Your message of "Wed, 24 Dec 1997 15:13:40 EST." <Pine.SUN.3.95.971224144845.28624G-100000@beethoven.bunyip.com>
Date: Fri, 26 Dec 1997 23:41:42 -0800
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID: <9712262346.aa26429@paris.ics.uci.edu>
Sender: owner-urn-ietf@Bunyip.Com
Precedence: bulk
Reply-To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Errors-To: owner-urn-ietf@Bunyip.Com

>You currently have your name on an Internet-Draft document that says
>it is a URI syntax document.  To date, you have personally rejected
>100% of the URN WG chairs' required edits to make a document that 
>reflects the work that has been carried out in the IETF's URN Working Group.

That is an interesting interpretation of history.  You asked for no
requirements to be placed on URNs, so I placed no requirements on them.
You asked for me to reference RFC 2141, and I did exactly that.
You asked that we not say things about URNs in a document titled
"URL: Syntax and Semantics", and so Larry first removed what I had
written about URIs and later we changed the document title and rewrote
the entire section.  When the eleventh draft of this review (uri-00)
was completed on November 5th, Keith asked for your comments.
You made no comments that I am aware of until December 10, and even
then you did not send them to me.

When I finally did receive your comments, I provided counterexamples
to every claim you made.  There is no basis for your "required edits",
and therefore I have no reason to make them.

>Thus, your document is just that -- your document, and not a URI syntax
>and semantics document, not an IETF document that accurately reflects
>the syntax and semantics of all URIs as defined within the auspices
>of the IETF.

My document (and yes, it is my document, in addition to Larry and TimBL)
is quite capable of standing on its own.  If you would direct your comments
to what is actually written in the document, instead of what you imagine a
guy like me would be tempted to write, then maybe we can make some progress.

>Your arguments against the "# fragment" and relative URNs are, again, _your_
>arguments -- you are countering the entire output of the URN WG with
>your own interpretations and opinions. THese are all discussions that
>have been held on the URN mailing list, and results are well-documented.
>I'm not going to get back into attempting to justify them to you here; I
>don't see why I have to, as you are not the jury and arbiter on URNs.

And as I said before, the #fragment is not part of the URN.  It doesn't
make sense for the URN working group to have any opinion regarding them,
just as you can't forbid the use of anchor href attributes in HTML.
The #fragment part of a URI-reference is not in your ballywick.
Plenty of URN-based counterexamples have been provided, so at this
point I don't particularly care what was said about them on the URN WG.
They are part of the URI architecture, of which URN is only one element.
They are an optional feature that is checked for and removed from a
reference BEFORE the parser knows whether it is looking at a URL or URN,
so the URN parser can't do a bloody thing about it.  The only way we could
remove them from the syntax is to exclude the use of URNs from the
URI-reference, which would completely oppose the reason for having
a URI syntax in the first place.

>It is in fact this stone-wall editing that caused me concern over the
>whole idea of trying to develop a URI syntax document.  However, I
>have been attempting to work with the material that was put on the table.

No you haven't.  You tried to bypass it.  If you had simply sent your
comments on the actual text of the draft, then we could have discussed them.
Instead, you butchered 14 months of hard work and claimed the result
represented the URI syntax.  Well, I know better -- the URI syntax is
defined by the implementations of protocol libraries like libwww-perl
(which I wrote) and libwww (which is the basis for most URI-enabled
applications).  They allow the usable set of URI schemes, including "urn",
to be extended and dynamically loaded with the implicit assumption that
all schemes obey the requirements described in
<draft-fielding-uri-syntax-01.txt>.  That is how we are able to progress
the URI syntax as a Draft Standard.  It is both technically sound and
demonstrated by deployed applications.

>It's pretty hard to cooperate with a stone wall.  The end result of this
>obstinate lack of cooperation may either be inaccurate documentation or
>the IETF/W3C may have to do without a URI syntax document for now.  
>That seems pretty sad, and I will re-emphasisze it's not because of
>_any_ lack of effort to participate on the URN WG's part.

We have a URI syntax document that meets all of the URN WG's requirements,
as well as those of HTTP, HTML, and XML.  I suggest you read it and make
comments, but don't expect your comments to have any special status just
because you are the chair of a WG.  If the comments are technically
sound, then the WG should be capable of defending them.  The comments
you have made so far have not been technically sound.  Right now the
only excuse you have for not approving the document is that I am one
of the authors, and last I checked that wasn't a valid excuse either.
After all, I won't be able to change the document once it becomes an RFC,
so there is no point in imagining "alarm bells".

....Roy