Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

["Martin J. Dürst" <[e-mail]>]

Hello John, others,

On 2014/04/14 22:11, John C Klensin wrote:
> Hi.
>
> It seems wise to call the attention of this broader group to
> something that is going on in URNBIS (and more generally).
> This message is a personal opinion.  It summarizes some
> discussions in and around that WG but is not an attempt to
> report on any sort of consensus.

First, it may help to give a direct pointer to an actual draft:

http://www.w3.org/DesignIssues/ModelConsequences


> RFC 3986 on Generic URI Syntax was an attempt to create a
> general syntax (and, despite its title, partial semantics) for
> an extremely general set of resource identifiers, using
> experience with and developments from URLs as a starting point.
> The general URI concept was intended to including URLs, URNs,
> and possible future types.

For crucial background reading, please see
http://www.w3.org/DesignIssues/ModelConsequences.
Please don't come back here before you have read it!


> That approach worked for URNs as
> long as they preserved the very narrow definitions and syntax of
> RFC 2141 but without taking advantage of any of the provisions
> for extensibility ("future use") in that specification.

Please have a look at 
http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/. This was 
worked out and written in collaboration with people from the IETF and 
from the library community.


> In the nearly 20 years since RFC 2141 was published, experience
> with URNs in various communities has demonstrated the need, with
> some URN types (NIDs), to be able to specify operations or
> retrieval of metadata as well as objects and for partial
> retrieval or other operations on either metadata of the objects
> themselves.  At the same time, there have been forceful
> discussions in information science, library, museum, and
> publisher communities about the fundamental differences between
> locators and names (which much of that community calls
> "identifiers", excluding locators from that category) and the
> disadvantages of mixing the two concepts.

When it comes to books, and therefore in the library community, such a 
distinction is very natural. But there are still many use cases where it 
may make sense to be able to use one or the other kind of identifier in 
the same field. That's what URIs are all about.

To use an (of course incomplete) analogy, it's a bit like the Internet 
and IP numbers: Before the Internet, there were various networks, and 
they used various different ways to identify their nodes. The Internet 
integrated them into a single address space, leading to great network 
effects. URIs do very much the same, just on a different level.


> That might be mostly
> a theoretical issue except that the URNBIS WG has found it
> impossible to define the functionality it needs while remaining
> within the syntax and semantic constraints of RFC 3986 (at least
> without creating obvious and very ugly kludges).

Your draft in question mentions quite a few requirements, but doesn't 
discuss at all how they would lead to kludges. Actually reading through 
the requirements, except for a couple of them, I have difficulties 
seeing even a shadow of needs for separate syntax. The conclusion of 
your draft comes out of the blue if it were not for the title.


> The WG is now considering
> draft-ietf-urnbis-urns-are-not-uris-00, which proposes to
> separate URNs from RFC 3986, presumably leaving the latter with
> URLs and name-like things that are not URNs.   It may be worth
> noting that there is now work in W3C and WHATWG on a new URL
> definition.  The intent of that work includes eventually
> superceding 3986 (and 3987), at least for URLs, so there are
> multiple forces working to dismember RFC 3986.

As Julian already said, the WHATWG work is of a completely different 
nature and cannot and should not be used as a justification for creating 
more confusion.


> However, the
> URNBIS draft is intended to narrowly focus on the needs of URNs,
> rather than trying to boil the URI ocean.

Focusing narrowly on perceived differences in a specific case isn't the 
way to move forward.


> Those who are interested in this topic should probably take a
> look at the draft and the discussions during the last week or so
> on the URN mailing list
> (http://www.ietf.org/mail-archive/web/urn/).   That list has
> been fairly low-volume, so looking at those messages should not
> be burdensome.  Discussion should also occur on that list unless
> there are very broad issues that belong here.

Trying to split URI syntax is to the Web as e.g. claiming that servers 
and clients should be assigned different types of IP addresses. As such, 
this is in and of itself a broad issue that shouldn't be left to a list 
with limited coverage.


Regards,    Martin.