Subject: Re: [urn] 2141bis questions - (1) Section 3.2 Namespace specific string syntax

From: John C Klensin <[email-masked]>
Date: Wed, 21 Jan 2015 07:34:52 -0500

Since there has been no other response to this one...

--On Tuesday, December 23, 2014 11:32 -0700 Peter Saint-Andre -
&yet <[email-masked]> wrote:

> On 12/23/14, 10:12 AM, John C Klensin wrote:
>...
>> Section 3.2 Namespace specific string syntax, doesn't seem
>> completely clear when p-, q-, or f-components are possible,
> 
> As I understand it, the NSS is part of the assigned-name, so
> those components don't occur within the NSS.

See below.
 
> Perhaps did you mean to reference Section 3.3 for this note?
> Or by referencing Section 3.2 did you mean to imply that
> 2141bis needs to be more clear about rules or guidelines for
> when those components are allowed ("possible") in the context
> of a given namespace?

More the former, but the issue is a combination of several
things that I probably should have separated:

(1) It isn't clear when p-, q-, and/or f-components are allowed.
That may be a matter for the Registration material in Section 8
and/or the template in Appendix A.  Or not.

(2) Unless we separate it very carefully, the question of "what
is the NSS" is very closely connected to how we interpret 3986
syntax components (incorporating both the recent 3896 flap and
urnbis-semantics-clarif by reference and the question of whether
two URNs are equal.

>> nor
>> is it clear about any syntax issues within those components.
> 
> To date, we have simply pointed to RFC 3986 regarding the
> *syntax* of those components.

The recent controversy about the use of 3986 fragments for file
purposes confirms my impression that doing so is a bad idea.

> Here again, we might provide some guidelines about how a given
> namespace would best handle syntax within those components. Or
> we could leave it completely up to the namespace definition,
> as long as the syntax is consistent with the RFC 3986
> definitions.
> 
> I would prefer the latter.

So would I.  My impression is that some of the 3986 advocates
claim that we can't do that except on a per-scheme basis.  If we
can't, we may have other problems.  I personally also prefer to
leave it to the namespace definitions, but then we need a bit
more text about those definitions.

And I am still very concerned about the implications of the
Hamza mess to anything based on the IDNA model (which PRECIS was
both before and after the definitional change).  We might need
to talk about that.

    john