Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin"

From: John C Klensin <[email-masked]>
Date: Fri, 06 Feb 2015 04:12:30 -0500

--On Wednesday, January 14, 2015 07:45 +0100 Julian Reschke
<[email-masked]> wrote:

> On 2015-01-11 08:57, Sean Leonard wrote:
>> ...
>> At broad-scope, it appears that the UTF-8/Unicode assumption
>> in urn: URIs is softened in this draft, compared to RFC 2141.
>> Maybe I missed something awhile back, but why is that? I
>> thought that all URNs are UTF-8/Unicode, and that made
>> everything nice and consistent. ...
> 
> I thought URNs are RFC3986-URIs, in which case they are
> limited to the characters allowed per RFC 3986. Am I missing
> something here?

Not as far as I can tell.  If either of you believe that
something else is needed in the document, please suggest
specific text and where to put it.

best,
    john

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 09 Feb 2015 16:00:44 +0000

> specific text and where to put it.

Perhaps a Note somewhere to the effect that as URNs as defined in
2141bis are URIs, they automatically benefit from 3987.  That is, 3987
defines IRIs, and a (scheme-independent) mapping from IRI to URI, from
which it follows that someone who wants to define a Unicode-friendly
URN can say that that they define a URN namespace xyzzy [here].
Mostly they go on to write their identifiers in Unicode, subject to

 a) The constraints of 3987;

 b) The additional constraint that when mapped per 3987 to URI-land,
    their identifiers always satisfy the requirements of the xyzzy URN
    namespace;

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Feb 2015 12:14:02 -0500

--On Monday, February 09, 2015 16:00 +0000 "Henry S. Thompson"
<[email-masked]> wrote:

> Perhaps a Note somewhere to the effect that as URNs as defined
> in 2141bis are URIs, they automatically benefit from 3987. 

While 3987 is clearly dependent on 3986 and at least implicitly
incorporates some bits of it by reference, there is no
dependency at all, even an informative reference, from 3986 to
3987.   As far as I can tell, 3987 doesn't redefine URIs in any
way -- it just layers IRIs on top of URIs.

I don't see how one gets from those dependencies or IRIs on
URIs, with no dependencies in the other direction, to "URNs ...
automatically benefit from 3987", any more than I think it would
be appropriate to claim that, e.g., TCP automatically benefits
from HTTP.

In addition, because of the "syntax only" agreement, I don't
think we should go out of our way to encourage people to make
any more inferences from generic URIs to URNs than are
absolutely necessary.

   john

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 09 Feb 2015 19:38:43 +0000

John C Klensin writes:

> 3987.

Precisely.

> As far as I can tell, 3987 doesn't redefine URIs in any

Agreed.

> automatically benefit from 3987"

Precisely because the layering is 3987 on 3986.  It tells us how to
convert a string (which conforms to IRI syntax) containing supra-ASCII
Unicode characters into a string without such characters, which is
guaranteed to conform to URI syntax.

> any more inferences from generic URIs to URNs than are

For sure.  My argument goes the other way.  Suppose in the glorious
future to come, ISBN uris are defined to support auto-indexing requests,
so that urn:isbn:978-1-84749-079-7?operation=index&word=flower will
give me a list of all the pages on which the word 'flower' appears in
Jane Austen's _Persuasion_ (Oneworld Classics 2009 edition).  What if
I want an index for Proust's "Du Côté de Chez Swann" instead?  I can't
write urn:isbn:0-543-72205-8?operation=index&word=délicieux, it's not
a valid URI, ergo not a valid URN.  But it _is_ a valid IRI.  Which
you may say is not a particularly useful observation.  But I think it
is, because it means there is an RFC we can refer to which specifies,
in detail how to convert our valid IRIs into valid URIs, in this case 
urn:isbn:0-543-72205-8?operation=index&word=d%C3%A9licieux

At this point you say "yes, but we don't need 3987 for this, it's in
section 3.2 of 2141bis [1]."  Well, no, it isn't.  3.2 only covers the
NSS, not the q-component.  Furthermore, the wording of 3.2 is, it
seems to me, dangerously ambiguous.   When it says

   names that are valid in a namespace might contain characters that
   are not allowed in URNs according to the "pchar" rule (e.g.,
   characters outside the ASCII range or characters that are reserved
   in URIs, such as "/", "?", and "#").  Such a string MUST be
   translated into a conformant NSS before using it as a protocol
   element or otherwise passing it on to other applications.

it's very easy to read the phrase "names that are valid in a namespace
[despite containing e.g. accented characters]" as saying such
characters may be _allowed_ by the definition of a URN namespace.  I
guess you meant "real-world, pre-existing namespace" here, but then it
really doesn't make sense to go on to say

  namespaces SHOULD NOT allow characters outside the basic Latin
  repertoire

which a) now does seem by 'namespaces' to mean 'URN namespace
definitions' and b) contradicts the ABNF.  urn: URIs themselves _do
not_ consist of _anything_ that's not a pchar -- the 'syntax only'
agreement doesn't give you any wiggle room on that, as I understand
it.  That 'SHOULD NOT' has to be a 'MUST NOT'.  I think that in turn
that means you really do need to say just a bit more about the
difference between the strings people may wish to use for various
purposes and the syntax of urn: URIs, as in the above example.

I don't care very much if you use 3987 for that purpose, or not, I
just thought it would be better to avoid re-drawing the blueprint for
the wheel.

ht

[1] http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-09#section-3.2