Rationale for urn: requested [was: [URN] draft-ietf-urn-nid-req-01.txt]

[Dan Connolly <[e-mail]>]

Leslie Daigle wrote:
>If you have an idea of a specific
> paragraph that belongs in a specific document, do _please_ make the
> suggestion to the list.

I suggest that section 2. "Syntax" of
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-syntax-04.txt

reflect the rationale for the urn: prefix. I don't have specific
wording to suggest because I don't understand the rationale.

Your message is the closest thing I've seen to evidence to
support this design. (Thank you! Finally!) But...

> Specifically, there were people who said they _needed_ the syntactic
> cue for their purposes  of using URNs, and no one who said they could
> not deal with it.

Sigh... I can sympathize with this. I'm guilty of chairing
enough meetings with this sort of compromise. But I really
don't like it, and I want to be really sure that the
choices were carefully considered, and that the resolution
is explicitly written down in the specs.

> Some of the desire for having the syntactic cue are for resolution
> reasons (e.g., being able to hand that _class_ of identifiers to a specific
> proxy that knows about existing RDS's),

I find this idea of a urn: proxy worrisome: the intent of the
URI design was that clients should be able to send _all_ unknown
URI schemes to a "default proxy." That Netscape 2.x, for example,
recognizes and proxies urn: but not isbn: is a hack and a kludge.


> and some are for weighting
> clues (e.g., prefer URNs to URLs).  _Yes_, you could keep a table fo which
> identifier was which type, but that's an implementation answer, and does
> not seem to be what general concensus said people wanted.

You can also keep these sorts of "hints" outside the identifier.
For example, HTML has separate attributes for HREF= and URN=.

So I don't find any of that evidence compelling.

I haven't read the entire URN-WG archive, but I have read much
of it, plus all of the following:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-syntax-04.txt
http://www.acl.lanl.gov/URN/http_res.txt
http://www.bunyip.com/research/ietf/urn-bof/urnframework.txt
http://www.netlib.org/utk/projects/rcds/rcds-tr/

and a bunch of other stuff, and I haven't found these
implementors' claims that the urn: cue is necessary or even useful.


> This issue was specifically brought up at the meeting in San Jose, and
> was documented in the minutes.   See
> 
>         http://www.bunyip.com/research/ietf/urn-ietf/sanjose.txt

As I wrote in another message: I did that: but the minutes only
state the conclusion. They don't give any of the evidence or reasons.

And anyway, in the IETF, the consensus at an IETF meeting
isn't binding: all official business is conducted via email.
(At least that's my understanding. Please correct me if
I'm wrong.)


> (by the way -- http://www.bunyip.com/research/ietf/urn-ietf  also
> contains the text of the group's charter).

Thanks for the URL! I'd like to see a few more of them flying
around here. Finding drafts etc. in email archives is kinda tedious.


-- 
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21