Subject: [urn] Brief review of draft-ietf-urnbis-semantics-clarif-01 and draft-ietf-urnbis-rfc2141bis-urn-09

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Mar 2015 10:15:38 -0800

Howdy,

I have not been particularly engaged in this work over the past year or so,
so this review is based on a read of the documents themselves and a
necessarily brief skim through the working group mailing list archives.
That may make me a reasonable approximation of the eventual reader, or
simply confused.  Please understand, though, that suggestions made are
intended simply to suggest ways to make the document set effective, not to
challenge anything about the current consensus.  If anything I suggest
would change the current consensus, please put that down to bad writing or
confusion on my part.

For draft-ietf-urnbis-semantics-clarif-01, I believe I understand the
necessity of pulling this decision into a separate document and getting
consensus around it.  Now that the consensus is done, however, I believe
the document could be folded back into 2141bis and that the result would be
stronger.  As I read the document now, the core statements that would need
to be folded into 2141bis are these:

   This specification removes URN semantics from the scope of RFC 3896
<http://tools.ietf.org/html/rfc3896>.
   It makes no changes to the generic URI syntax.  That syntax still
   applies to URNs as well as to other URI types.
<snip>
   In particular, the generic URI syntax for path segments that appear
   after the NID and NSS of a URN,
<snip>
   is unchanged, but the terms for
   those path segments, "query" and "fragment" become, for URNs, terms
   of convenience that are defined in URN-specific ways as p-components,
   q-components, and f-components [RFC2141bis
<http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01#ref-RFC2141bis>].

<snip>
   the concern that led to this document was a desire to
   accommodate URN components that would be analogous to the query and
   fragment components of generalized URNs but that might have different
   properties.  For many cases, the analogy cannot be exact.

The security considerations would also have to be folded into 2141bis.

I realize that this is a somewhat radical proposal, given the working group
history, but I think having a single document with that text in it would be
adequate to the purpose and simpler.  (Basically, we don't need to have the
working group history recapitulated in the document set)

For draft-ietf-urnbis-rfc2141bis-urn-09,  some general comments.

First, the document currently has this text:

This document rests on two key assumptions:

   1.  Assignment of a URN is a managed process.

       A string that conforms to the URN syntax is not necessarily a
       valid URN, because a URN needs to be assigned according to the
       rules of a particular namespace (in terms of syntax, semantics,
       and process).

   2.  The space of URN namespaces is itself managed.

       A string in the namespace identifier slot of the URN syntax is
       not necessarily a valid URN namespace identifier, because in
       order to be valid a namespace needs to be defined and registered
       in accordance with the rules specified in this document.

These appear to be critically important, and getting them fixed in the
readers'
minds early seems to be a good thing.  I worry, though, that the explanatory
text below the bullets is delving into the complexity at the very moment
you want the reader to be focused.  I'd suggest adapting this slightly:

This document rests on two key assumptions:

   1.  Assignment of a URN is a managed process.
   2.  The space of URN namespaces is itself managed.

While other schemes may allow identifiers to be freely minted,
this is not the case for URNs.  The syntactical correctness of a
string appearing after "urn:" is not sufficient to make it a URN; both
the namespace identifier and namespace specific string must be registered
or generated according to the rules given for it to be a valid URN.

​The document currently has this text:

   Depending on the rules governing a namespace, 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.  Translation is done by percent-encoding each
   disallowed character using the method defined in Section 2.1 of
   [RFC3986] <https://tools.ietf.org/html/rfc3986#section-2.1>.  Note
that the "%" character is allowed only for the
   purpose of percent-encoding.

​I don't believe that this is clear that urn:nid:nss is de facto a protocol
element, so I worry that you may see folks creating urn:nid:non-pchar
productions in specific applications, with the presumption that they must
be percent encoded only when being passed outside that context.  That seems
to me fragile, and I'd suggest the following replacement text:

   Depending on the rules governing a namespace, names that are valid in
   a namespace might contain characters that are not found in the
   "pchar" production above (e.g., characters outside the ASCII
   range or characters that are reserved in URIs, such as "/", "?", and
   "#").  While these may be valid names, they are not valid URNs
    until those strings are translated into a conformant NSS.
   Translation is done by percent-encoding each
   disallowed character using the method defined in Section 2.1 of
   [RFC3986] <https://tools.ietf.org/html/rfc3986#section-2.1>.  Note
that the "%" character is allowed only for the
   purpose of percent-encoding.

3.3.1. has this text:

As described under Section 4
<https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-09#section-4>,
the p-component SHALL be taken into
   account when determining URN equivalence.

It is not actually described in section 4 specifically, though the document
does have this:

If a q-component or f-component (or both) are included in a URN, they
   MUST be ignored for purposes of determining equivalence.

For completeness, I suggest that the p-component text be added to section 4.

The document currently has this text:

   Ultimately, specifications of where it
   is appropriate to use URNs, or URNs created within particular URN
   namespaces, are the responsibility of descriptions of individual URI
   schemes and contexts; this specification cannot possibly anticipate
   all of the relevant cases.

I believe that including both "schemes and contexts" is confusing here,
because the main point is that these are likely to be context dependent
(e.g. they are valid in some SNMP MIB slots and not others, so defining it
in terms of an "SNMP" uri won't work.)  While there may be some where there
is a single protocol context per scheme, that is still a context.  I
suggest eliding "schemes and".

The document currently has this text:

   However, a single resource can have
   more than one URN assigned to it for different purposes (e.g., some
   numbers might be valid identifiers in two different identifier
   systems, where the namespace identifier differentiates between the
   resulting URNs).

A more concrete example would be very welcome here, as this seems likely to
be open to confusion.  The RFC 5031 emergency services may provide one
(e.g. urn:service:counseling.mental-health and
urn:service:counseling.suicide may be the same resource), but any concrete
example would likely be an improvement.

The document currently has this text:

   All two-letter strings, and all two-letter strings followed by "-"
   and any sequence of valid NID characters, are reserved for potential
   use as country-code-based NIDs for eventual national registrations of
   URN namespaces.  The definition and scoping of rules for allocation
   of responsibility for such country-code-based namespaces is beyond
   the scope of this document.

This matches current practice.  I note, however, that this was a source of
contention when New Zealand wanted to create country-code-based name space
(see rfc4350).  The interim step taken in discussion with the folks on the
URN-NID list of the time was to allocate the three-letter ISO country as a
NID.  You may want to add advice to the designated expert on this point, so
that three-letter NIDs which match country codes are considered from that
angle.

regards,

Ted

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 15:09:16 -0500

Ted,

Thanks for the careful reading.

Personal comments, no particular hats on except when I discuss
the document editing process...

--On Friday, March 06, 2015 10:15 -0800 Ted Hardie
<[email-masked]> wrote:

>...
> For draft-ietf-urnbis-semantics-clarif-01, I believe I
> understand the necessity of pulling this decision into a
> separate document and getting consensus around it.  Now that
> the consensus is done, however, I believe the document could
> be folded back into 2141bis and that the result would be
> stronger.  As I read the document now, the core statements
> that would need to be folded into 2141bis are these:
> 
>    This specification removes URN semantics from the scope of
> RFC 3896 <http://tools.ietf.org/html/rfc3896>.
>    It makes no changes to the generic URI syntax.  That syntax
> still    applies to URNs as well as to other URI types.
> <snip>
>    In particular, the generic URI syntax for path segments
> that appear    after the NID and NSS of a URN,
> <snip>
>    those path segments, "query" and "fragment" become, for
> URNs, terms    of convenience that are defined in URN-specific
> ways as p-components,    q-components, and f-components
> [RFC2141bis
>    accommodate URN components that would be analogous to the
> query and    fragment components of generalized URNs but that
> might have different    properties.  For many cases, the
> analogy cannot be exact.
> 
> I realize that this is a somewhat radical proposal, given the
> working group history, but I think having a single document
> with that text in it would be adequate to the purpose and
> simpler.  (Basically, we don't need to have the working group
> history recapitulated in the document set)

I don't have any problem with this in principle, but doing it
and having the resulting document read smoothly is a fair amount
of work and somewhat error-prone.  It certainly cannot be done
before the I-D cutoff (I can probably spin up one more version
of the semantics piece by Monday and Peter has a working draft
of 2141bis (and a lot of questions) in hand so, assuming he has
time to look at it, I'd expect that to be posted sometime over
the weekend.  I doubt that I can even get a consolidated
document done and checked before the end of the month,
especially if I do come to Dallas (still thinking about it).

>        A string that conforms to the URN syntax is not
> necessarily a        valid URN, because a URN needs to be
> assigned according to the        rules of a particular
> namespace (in terms of syntax, semantics,        and process).
> 
>        A string in the namespace identifier slot of the URN
> syntax is        not necessarily a valid URN namespace
> identifier, because in        order to be valid a namespace
> needs to be defined and registered        in accordance with
> the rules specified in this document.
> 
> These appear to be critically important, and getting them
> fixed in the readers'
> minds early seems to be a good thing.  I worry, though, that
> the explanatory text below the bullets is delving into the
> complexity at the very moment you want the reader to be
> focused.  I'd suggest adapting this slightly:
> 
> this is not the case for URNs.  The syntactical correctness of
> a string appearing after "urn:" is not sufficient to make it a
> URN; both the namespace identifier and namespace specific
> string must be registered or generated according to the rules
> given for it to be a valid URN.

Wfm and, IMO, an improvement in other ways.   "Freely minted"
feels a little too much like English-specific jargon to me, so
I'd appreciate suggestions of other wording or will use
something like "freely chosen and assigned".   Modulo that, I'll
make this change in the working draft unless someone objects.

One caution: I think the above is ok, but note that we may still
not have completely resolved just how much of what follows
"nid:" is the NSS versus other stuff.  This has been discussed a
bit on the list; the current syntax in 2141bis puts p-, f-, and
q- components after the NSS rather than as part of it.

>    Depending on the rules governing a namespace, 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.  Translation is done by
> percent-encoding each    disallowed character using the method
> defined in Section 2.1 of    [RFC3986]
> <https://tools.ietf.org/html/rfc3986#section-2.1>.  Note that
> the "%" character is allowed only for the
> ​I don't believe that this is clear that urn:nid:nss is de
> facto a protocol element, so I worry that you may see folks
> creating urn:nid:non-pchar productions in specific
> applications, with the presumption that they must be percent
> encoded only when being passed outside that context.  That
> seems to me fragile, and I'd suggest the following replacement
> text:
> 
>    Depending on the rules governing a namespace, names that
> are valid in    a namespace might contain characters that are
> not found in the    "pchar" production above (e.g., characters
> outside the ASCII    range or characters that are reserved in
> URIs, such as "/", "?", and    "#").  While these may be valid
> names, they are not valid URNs     until those strings are
> translated into a conformant NSS.    Translation is done by
> percent-encoding each
>    disallowed character using the method defined in Section
> 2.1 of    [RFC3986]
> <https://tools.ietf.org/html/rfc3986#section-2.1>.  Note that
> the "%" character is allowed only for the

Ok if others agree, but I'd suggest "translated into a
conformant URI" instead of "translated into a conformant NSS" to
avoid the issue described above.  Or we could try more text. 

> <https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-
> 09#section-4>, the p-component SHALL be taken into

> It is not actually described in section 4 specifically, though
> the document does have this:
> 
> If a q-component or f-component (or both) are included in a
> URN, they    MUST be ignored for purposes of determining
> equivalence.
> 

I/we were specifically told to remove p-component from the
numbered list in section 4.1 because the WG wanted it to be case
sensitive.   I could add another sentence to the fifth full
paragraph so it would read:

	"If a p-component is included in a URN, it must be
	identical (including case sensitivity) in the strings
	being compared.  If a q-component or f-component (or
	both) are included..."

Other suggestions welcome, but I think we need guidance from the
WG on this.

>    is appropriate to use URNs, or URNs created within
> particular URN    namespaces, are the responsibility of
> descriptions of individual URI    schemes and contexts; this
> specification cannot possibly anticipate    all of the
> relevant cases.
> 
> I believe that including both "schemes and contexts" is
> confusing here, because the main point is that these are
> likely to be context dependent (e.g. they are valid in some
> SNMP MIB slots and not others, so defining it in terms of an
> "SNMP" uri won't work.)  While there may be some where there
> is a single protocol context per scheme, that is still a
> context.  I suggest eliding "schemes and".

This is more complicated because the current text was an attempt
to work around the question of whether URNs generally are
expected to be used and function correctly in HTML "<a href>"
environments and generalizations from them.  Some will work,
some won't.  I wouldn't expect most SNMP URIs to work well in
those environments either.    Similarly, consider such
constructions as 
   ArbitraryScheme:...?x=urn:SomeNID:SomeNSS...

That is definitely valid 3986 syntax, but whether it makes sense
or not is certainly going to depend on the scheme as well as
other things.  

Also, Henry Thompson made different suggestion, which was to get
rid of "contexts" and make the offending sentence fragment read
"...individual URI schemes and their expected uses;".  The two
suggestions have somewhat different meaning. 

WG discussion is probably needed before we finalize text.

>    more than one URN assigned to it for different purposes
> (e.g., some    numbers might be valid identifiers in two
> different identifier    systems, where the namespace
> identifier differentiates between the    resulting URNs).
> 
> A more concrete example would be very welcome here, as this
> seems likely to be open to confusion.  The RFC 5031 emergency
> services may provide one (e.g.
> urn:service:counseling.mental-health and
> urn:service:counseling.suicide may be the same resource), but
> any concrete example would likely be an improvement.

Placeholder added to working copy.

>    All two-letter strings, and all two-letter strings followed
> by "-"    and any sequence of valid NID characters, are
> reserved for potential    use as country-code-based NIDs for
> eventual national registrations of    URN namespaces.  The
> definition and scoping of rules for allocation    of
> responsibility for such country-code-based namespaces is beyond
> This matches current practice.  I note, however, that this was
> a source of contention when New Zealand wanted to create
> country-code-based name space (see rfc4350).  The interim step
> taken in discussion with the folks on the URN-NID list of the
> time was to allocate the three-letter ISO country as a NID.
> You may want to add advice to the designated expert on this
> point, so that three-letter NIDs which match country codes are
> considered from that angle.

Arggh.  I'm not sure what you are suggesting.  It is a little
late in the game to be reserving three character strings for
3166-1 alpha-3 use and I see a bit of a slippery slope.  E.g.,
if we are going to advise experts to consider three-letter codes
in case they match present (and possibly past or future) 3166-1
alpha-3 codes, should we also advise looking out for language
codes or 3166-2 subdivisions codes, POSIX or other locale codes,
etc.?   Could you suggest some text?

best,
    john

---

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Mar 2015 12:50:47 -0800

Hi John,

Thanks for your quick reply.  Some additional thoughts below,

On Fri, Mar 6, 2015 at 12:09 PM, John C Klensin <[email-masked]> wrote:

> ​Understood, and the working group may have good reasons
to prefer not to make so big a change at this stage.​

> ​That makes sense to me, and I think that it would not impact
the basic point that syntactical correctness does not guarantee
validity.​

> ​A conformant URN would also work for me.​

> ​I don't have an opinion on what the comparison method should be
for p-component should be, I was merely noting that ​3.3.1 pointed
somewhere for guidance on it that did not appear to have that guidance.
​The draft currently requires that it be taken into account but does not
explain how to do so (or I missed it, which is entirely possibly).
​Given the parallel to path-absolute, I could see case-sensitive
comparison being desirable, and if that is the desire, then the text
above seems close, but likely needs to account for the case insensitivity
of the %-encoded parts (that is, you want case sensitivity for pchar-valid
portions, but the %-encoded parts are treated according to 6.2.2.1 of
RFC 3986)

> WG discussion is probably needed before we finalize text.
​It sounds like the WG understands the concern, and that there are
various possible wording to handle it.  One additional option might
be to shift to something like:

Ultimately, specification of where it is appropriate to use URNs, or URNs
created within particular URN    namespaces, should be in the descriptions
of the individual  contexts.

This is slightly more vaugue, but gets the point that there is no simple
answer here across.

> ​Well, I think there are two choices.  One is drop the restriction here
and stick the designated expert with determining when a request
is coming from a national authority to whom such a country-code
based namespace should be delegated.  If this document does
not remove this reservation, frankly, I'm not sure it ever will be removed.
Where the designated expert gets the budget for their headache pills
is an exercise left to the reader.

The other option is simply to note that in advance of this restriction
being relaxed some country-code-based name spaces have been allocated
by three letter code and that the designated expert may take this into
account.  I would not consider firm reservation there useful, just a
heads-up
to both parties that requesting a NID of USA may get pushback and why.

Thanks again for the quick reply,

Ted

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 16:16:49 -0500

> Thanks for your quick reply.  Some additional thoughts below,

I'm really anxious to move this stuff forward and will do
everything I can to reinforce careful and on-topic reviews like
yours :-)

Comments on your additional notes/thoughts were they seem
relevant below (with much trimming).
 
> to prefer not to make so big a change at this stage.

(This is about folding the "semantics" piece into 2141bis).
Really up to the WG.  If things are going to drag out anyway,
then finding time to fold the two together may be worthwhile.
On the other hand, I'd prefer that they not drag out and there
are significant risks of bad things happening if they do.​

>> something like "freely chosen and assigned".   Modulo that,
>> I'll make this change in the working draft unless someone
>> objects.
>> 
>> One caution: I think the above is ok, but note that we may
>> still not have completely resolved just how much of what
>> follows "nid:" is the NSS versus other stuff.  This has been
>> discussed a bit on the list; the current syntax in 2141bis
>> puts p-, f-, and q- components after the NSS rather than as
>> part of it.
>> 

Concur.

>> conformant URI" instead of "translated into a conformant NSS"
>> to avoid the issue described above.  Or we could try more
>> text.
>> 

I deliberately said "translated into a conformant URI" (perhaps
with a reference to 3986 and some hand-waving about syntax)
deliberately.   "A conformant URN" in this section would seem a
bit circular.  Or do you see that differently?

>> > <https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-u
>> > rn- 09#section-4>, the p-component SHALL be taken into
>> > It is not actually described in section 4 specifically,
>> > though the document does have this:
>> > 
>> numbered list in section 4.1 because the WG wanted it to be
>> case sensitive.   I could add another sentence to the fifth
>> full paragraph so it would read:
>> 
>> Other suggestions welcome, but I think we need guidance from
>> the WG on this.
>> 
> for p-component should be, I was merely noting that ​3.3.1
> pointed somewhere for guidance on it that did not appear to
> have that guidance. ​The draft currently requires that it be
> taken into account but does not explain how to do so (or I
> missed it, which is entirely possibly). ​Given the parallel
> to path-absolute, I could see case-sensitive comparison being
> desirable, and if that is the desire, then the text above
> seems close, but likely needs to account for the case
> insensitivity of the %-encoded parts (that is, you want case
> sensitivity for pchar-valid portions, but the %-encoded parts
> are treated according to 6.2.2.1 of RFC 3986)

Yes.  The reference to Section 4 was correct when the original
statement was there and should have been fixed, somehow, when we
took the p-component statement out, so you clearly identified a
real issue.

>> Also, Henry Thompson made different suggestion, which was to
>> get rid of "contexts" and make the offending sentence
>> fragment read "...individual URI schemes and their expected
>> uses;".  The two suggestions have somewhat different meaning.
>> 
> ​It sounds like the WG understands the concern, and that
> there are various possible wording to handle it.  One
> additional option might be to shift to something like:
> 
> Ultimately, specification of where it is appropriate to use
> URNs, or URNs created within particular URN    namespaces,
> should be in the descriptions of the individual  contexts.
> 
> This is slightly more vaugue, but gets the point that there is
> no simple answer here across.

Yes.  I'd like to hear from the WG (and Henry in particular)
rather than changing text several times.

>> >    All two-letter strings, and all two-letter strings
>> >    followed by "-"    and any sequence of valid NID
>> > characters, are reserved for potential    use as
>> > country-code-based NIDs for eventual national registrations
>> > of    URN namespaces.  The definition and scoping of rules
>> > for allocation    of responsibility for such
>> > country-code-based namespaces is beyond the scope of this
>> >    document.
>> > 
>> > This matches current practice.  I note, however, that this
>> > was a source of contention when New Zealand wanted to create
>> > country-code-based name space (see rfc4350).  The interim
>> > step taken in discussion with the folks on the URN-NID list
>> > of the time was to allocate the three-letter ISO country as
>> > a NID. You may want to add advice to the designated expert
>> > on this point, so that three-letter NIDs which match
>> > country codes are considered from that angle.
>> 
>> if we are going to advise experts to consider three-letter
>> codes in case they match present (and possibly past or
>> future) 3166-1 alpha-3 codes, should we also advise looking
>> out for language codes or 3166-2 subdivisions codes, POSIX or
>> other locale codes, etc.?   Could you suggest some text?
>> 
> not remove this reservation, frankly, I'm not sure it ever
> will be removed. Where the designated expert gets the budget
> for their headache pills is an exercise left to the reader.
> 
> The other option is simply to note that in advance of this
> restriction being relaxed some country-code-based name spaces
> have been allocated by three letter code and that the
> designated expert may take this into account.  I would not
> consider firm reservation there useful, just a heads-up

Speaking strictly as an individual participant, what would be
the problem or retaining the alpha-2 restriction (with and
without a trailing hyphen) and noting that there are other
strings that some entities might consider intrinsically reserved
for their use including 3166-1 alpha-3 codes and assorted
locality, etc., names and the review process might discourage
their use by other then the obvious parties?

Henry suggested that we should probably think about dispute
resolution policies for names, trademark issues, etc.  I had to
suppress a gag reflex, mentioned to him that the historic IANA
position on such issues (at least pre-ICANN) has been "not our
problem, you folks go work it out among yourselves", and
suggested he take the issue to the list, so your alpha-3 concern
may be an introduction to a more complex discussion.

best,
   john

---

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Mar 2015 13:30:46 -0800

On Fri, Mar 6, 2015 at 1:16 PM, John C Klensin <[email-masked]> wrote:

> ​I think "conformant URI" is fine, and a reference to 3986 there
would help. (I personally don't see "conformant URN" as
problematically circular, but it also not a huge advantage to have
it, so it sounds like "conformant URI" makes the​ best sense)

> rather than changing text several times.
​Sounds good.
​

> ​I think that is fine.  Given that the review process includes
urn-nid@ as well as the designated experts, it's also a fairly
general formulation.

> ​The only thing I really want to avoid is having someone say
"I have all the boxes ticked for a formal namespace, why
can't I have the 3-letter one I want?" where the designated expert
or review process sees a risk of an eventual country code
request.  Given that there is no mechanism for a two-letter
code being given, that would have to be a three letter code.
If there is a note in the document that this may be taken into
account, I think we've done what we need to.  Further
mechanisms than our normal appeals chain are not going
to help much, in my opinion, and I wouldn't spend any time
designing them.

regards,

Ted