Subject: Interpretation problems - perceived conflict between RFC 2141 and RFC 2396

From: Didier PH Martin <[email-masked]>
Date: Tue, 1 Jun 1999 21:29:12 -0400

Hi,

The message blow has been posted in the XML-DEV mailing list. Actually,
people from the XML-DEV discuss the usage of URN as XML name space reference
( CAUTION: a XML name space is not a URN name space). It seems that some
confusion is perceived between RFC 2141 and RFC 2396. Waht is your opinion
on this.

regards
Didier PH Martin
mailto:[email-masked]
http://www.netfolder.com

-----Original Message-----
From: Jeffrey E. Sussna [mailto:[email-masked]]
Sent: Tuesday, June 01, 1999 5:36 PM
To: 'Didier PH Martin'; 'XML Dev'
Subject: RE: Just require URLs

There appear to be conflicts between RFC's 2396 (URI: Generic Syntax) and
2141 (URN Syntax). Interestingly, RFC 2396 is not specified as updating RFC
2141. In any case:

*Both specs agree that a URN must be preceded by the scheme "urn".

*RFC 2141 states that the forward-slash (and other reserved) character
should not be used in unescaped form, as its "applicability" is (or was at
time of writing, 5/97) still open to debate.

*RFC 2396, on the other hand, states that forward-slash (and other reserved)
character should not be used in unescaped form IF "the data...would conflict
with the reserved purpose". This seems to imply that it's ok to use "/"
unescaped if it denotes a hierarchical namespace.

*RFC 2396 APPEARS to state that an "authority" must be preceded by
double-forward-slash. It is not totally clear to me whether this applies to
the NID component of a URN.

First of all, I would be interested in opinions as to the above statements.
Secondly, I would be interested in opinions as to the advisability of going
ahead and using unencoded forward-slashes to denote hierarchy within a URN.
I need to denote such hierarchy, and it seems hard to believe that
forward-slash wouldn't be defined to denote such hierarchy. Thus encoding it
seems like a waste of time, effort, and an unnecessary loss of readability.

Jeff

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Didier PH Martin
> Sent: Tuesday, June 01, 1999 12:12 PM
> To: 'XML Dev'
> Subject: RE: Just require URLs
>
>
> Hi Jonathan,
>
> Jonathan said:
>     Under the definition of URN in 2396, a URN is any URI
> whose intention is
> to reference an abstract resource, act primarily as a name,
> and/or not be
> retrievable via a network. Under the definition in 2396,
> "urn" defines a
> scheme/namespace (URI namespace) whose intention is to serve
> *only* for
> URNs, however the spec suggests that any scheme e.g. "http"
> can serve to
> define a URN, given the definition of URN in 2396 (part of
> which my earlier
> message quotes).
>
>     So, my reading of RFC 2396 and the XML namespace spec leads me to
> conclude that all URIs used as XML namespaces are properly
> URNs regardless
> of the URI scheme prefix.
>
> Didier says:
> This is not what RFC 2396 says. You are right when you say
> that a URI coudl
> be a URL or a URN. However a HTTP scheme cannot be considered as a URN
> because it is already part of the URL space.
>
> If however you create a name space having as NID "HTTP" then
> yes this would
> be a URN. However each "/" would have to be encoded. Thus, a
> URN cannot be
> with "/" as delimiters. Obviously we'll have to create a new RFC for
> hierarchical name spaces having "/" as delimiters but
> actually you would
> have to encode each "/". Thus your name space would look like:
>
> urn:http:domain.com%(hex for /)context%(hex for /)etc...
>
> The above URN confor to RFC 2141 specs. However the URL:
> http://domain.com/context/etc... do not conform to RFC 2141
> and thus cannot
> be said to be a URN.
>
> regards
> Didier PH Martin
> mailto:[email-masked]
> http://www.netfolder.com
>
>
> xml-dev: A list for W3C XML Developers. To post,
mailto:[email-masked]
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To (un)subscribe, mailto:[email-masked] the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:[email-masked] the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:[email-masked])

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 2 Jun 1999 09:30:08 -0400

Howdy,

Thanks for forwarding the questions.

> unescaped if it denotes a hierarchical namespace.

Actually, I read the words to the contrary.  I read these words to
say that unescaped "/" should be interpreted by the rules of hierarchy
laid out in 2396, and any other expected interpretation requires
the character to be escaped.

2396 defines a particular mechanism for interpreting and manipulating
hierarchical structures of URIs -- denoted by the use of the forward
slash.  This includes the ability to make relative references, etc,
that we were never able to reconcile with the notion of providing
fixed, persistent references (URNs).

Rather than try to effect changes to that interpretation of "/" in
URIs, or subject URNs to all existing URI rules for handling
that hierarchy, we decided to abstain from the use of the character.

Note that this does not mean namespaces cannot use "/" to denote
hierarchy -- if it is escaped, it can be used for hierarchy as
it is understood local to a particular namespace (i.e., browsers
and editors will not attempt to create or interpret relative URIs
of them).

> the NID component of a URN.

Again, this is "authority" as it is defined by the URI syntax, subject
to the particular interpretation as laid out in 2396.  There are
other URI schemes that do not have an authority component preceded
by "//".

> First of all, I would be interested in opinions as to the above statements.

See above.

> ahead and using unencoded forward-slashes to denote hierarchy within a URN.

Don't.

:->

More seriously, look a little more closely at the problem, and I
think you'll see the distinction we're trying to draw.

> seems like a waste of time, effort, and an unnecessary loss of readability.

a) don't forget that URNs are not primarily targetted at being
   human-readable
b) is the hierarchy you are looking for really all the bells &
   whistles of relative URIs as found in 2369, in which case you
   may not be after a URN afterall.  You may want the resolution
   mechanisms laid out in, for instance, the NAPTR RDS, but those
   are already described in generic terms as being applicable to
   all URIs, not just URNs.

Leslie.

--

------------------------------------------------------------------------

"My cat has all the answers.  But she claims     Leslie Daigle
   she doesn't know the questions."              [email-masked]

------------------------------------------------------------------------

---

From: Ryan Moats <[email-masked]>
Date: Wed, 2 Jun 1999 10:15:00 -0500

Is somebody playing with the list?

This is ancient, and I didn't send it...

Ryan

>
> Thanks to everyone for comments, and especially thanks to Leslie for
> putting them together.  Attached is the pre-release #3 of
> the syntax draft (or is it #4?).
>
> Changes from last pre-release are:
>
> Addition of reserved character set and discussion section (2.3).
> "%" and "/" are now moved to the reserved character set.  The
> discussion of "%" and %-encoding now moved to this section.  Discussion
> added for "/".
>
> Any more comments, or can we go with this as -02?
>
> Ryan

---

From: Michael Mealling <[email-masked]>
Date: Wed, 2 Jun 1999 11:22:49 -0400

> Is somebody playing with the list?

Could be. The [email-masked] is pristine so it couldn't have
come from there...

> This is ancient, and I didn't send it...

Very ancient. I've always thought it was just the god o' the net playing
tricks on us, pulling up stuff from a long time ago for no reason.

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]