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

[Graham Klyne <[e-mail]>]

John,

Further to my other comments...

On 14/04/2014 15:35, John C Klensin wrote:
> ...  But
> what is driving this change is not theory, it is a need for new
> functionality that just doesn't fit into the locator-oriented
> 3986 model.  That new functionality will require either new
> syntax or old syntax with different semantics than those
> specified in 3986.

Maybe this is part of what is missing from your draft.  RFC3986 semantics are 
pretty minimal/malleable, so I'm struggling to understand what you might need to 
add that violates RFC3986.  (The main possible problem I can see would be 
possible interference with relative reference resolution, but that's not a 
problem if you avoid using '/' - which urns currently do)

> ...  Just as there is no such thing as a
> 3986-conforming library that can completely and generally handle
> queries (other than parsing the query away from other components
> and dispatching it properly), such libraries are not likely to
> be able to fully process URNs.

>
> Another piece of that issue is that comparison of two URNs for
> equality is,  in the general case, a rather different kind of
> operation than comparison of two URLs; I would not expect a
> URL-based algorithm (e.g., a RFC3986-conformant library) to be
> able to get URN comparisons right, at least without NID-specific
> action routines.

So there's nothing new there.  RFC3986 parsing is just a start - URI schemes all 
tend to have their own specific behaviours.  (Which is part of why there is some 
push-back against arbitrary introduction of new schemes.)  I'm not yet seeing 
the problem of adding NID-specific action routines as long as they don't vilate 
(minimal) RFC 3986 constraints.

#g
--