Subject: [urn] 2141bis-06 -syntax and internationalization (maybe 3406bis too)

From: John C Klensin <[email-masked]>
Date: Wed, 22 Jan 2014 04:01:36 -0500

Hi.  In reviewing 3406bis, I discovered what may be some issues
in the basic syntax definitions in 2141bis that might require
changes to 3406bis as well.

draft-ietf-urnbis-rfc2141bis-urn-06 defines the syntax for an
NID in terms of <alphanum> plus embedded hyphens.  Since
<alphanum> (from 3986) is restricted to ASCII letters and
digits, non-ASCII characters are prohibited, even in %-escaped
form.  That seems wise to me, but I want to be sure everyone is
aware of it.    Also, names with leading digits have a long
history of causing problems.  Noting that informal namespaces
start with "urn-" and not with the digits that follow, unless
there is a good reason to allow NIDs with numeric digits, I
think we should disallow them.  So...

Suggestions:

	(1) In Section 4, change 
	
	Old:
		NID      = (alphanum) 0*30(ldh) (alphanum) 
	New:
		NID      = (ALPHA) 0*30(ldh) (alphanum) 
	
	and, if the editor things it necessary, change
	
	Old:
		; alphanum is defined in RFC 3986
	New:
		; alphanum is defined in RFC 3986
	   ; ALPHA is defined in RFC 5234
	
	(2) Add a brief "Internationalization" section, as
	required by RFC 2277, to explain why NIDs are expected
	to remain ASCII-only protocol identifiers.

In addition, the current definition for NSS is based on pchar,
which allows percent-encoded non-ASCII characters as well as
other things.  Given the somewhat confused state of IRIs [1] and
the stability and persistence requirements for URNs, I'd prefer
that we restrict the use of percent-encoding in NSSs to ASCII
characters only, i.e., escaping the reserved characters of RFC
3986.   

If that is not possible, i.e., if people are convinced that
non-ASCII characters must really be allowed in the NSS part of a
URN, I believe that 3406bis should discourage that usage and
should add an i18n section to the template that specifies
whether or not non-ASCII characters are permitted (with a clear
default of "no") and, if they are, explain why and under what
circumstances.  That template change would suggest that 3406bis
should have an "Internationalization" section as well.

best,
    john

[1] As far as I can tell, we've got an IETF Proposed Standard
(RFC 3987) that is sufficiently in need of updating that we
chartered a WG to do the work, a WG that shut down without
either doing that work or clarifying applicability, and a W3C
effort that could produce either a competing standard or at
least clarifications/ interpretations that would fork 3987 in
practice if not in theory.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Jan 2014 17:03:26 -0700

Hi John, thank you for raising these issues.

On 01/22/2014 02:01 AM, John C Klensin wrote:
> think we should disallow them.  

I'll note that the following NIDs are already registered:

3gpp
s1000d
web3d

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

Have these caused harm? Personally I am not worried about them, but I
might be missing something.

> So...

We definitely need that, yes.

> should have an "Internationalization" section as well.

Personally I am not convinced that non-ASCII characters must be allowed
in the NSS part of a URN, so I find your proposal acceptable.

Peter

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Jan 2014 05:13:38 -0500

--On Thursday, January 23, 2014 17:03 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> Hi.  In reviewing 3406bis, I discovered what may be some
>> issues in the basic syntax definitions in 2141bis that might
>> require changes to 3406bis as well.
>> 
>> form.  That seems wise to me, but I want to be sure everyone
>> is aware of it.    Also, names with leading digits have a long
> Have these caused harm? Personally I am not worried about
> them, but I might be missing something.

Of course, only the first of these would violate a "no leading
digits" rule.  But the existence of that one may be a compelling
argument to say "too late to impose a more restrictive,
no-leading-digits, rule, let's move on".

>...
 
>> other things.  Given the somewhat confused state of IRIs [1]
>> and the stability and persistence requirements for URNs, I'd
>> prefer that we restrict the use of percent-encoding in NSSs
>> to ASCII characters only, i.e., escaping the reserved
>> characters of RFC 3986.   
>> 
>> non-ASCII characters must really be allowed in the NSS part
>> of a URN, I believe that 3406bis should discourage that usage
>> and should add an i18n section to the template that specifies
>> whether or not non-ASCII characters are permitted (with a
>> clear default of "no") and, if they are, explain why and
>> under what circumstances.  That template change would suggest
>> that 3406bis should have an "Internationalization" section as
>> well.
> 
> Personally I am not convinced that non-ASCII characters must
> be allowed in the NSS part of a URN, so I find your proposal
> acceptable.

As we know from IDNA, PRECIS, and other work, allowing non-ASCII
characters in identifiers requires that we dive into a rather
large can of venomous serpents (not merely open one containing
worms).  IMO, there should be a really compelling argument for
going down that path.  I'm not convinced either... and strongly
suspect that compelling argument doesn't exist.

thanks,
   john