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

From: John C Klensin <[email-masked]>
Date: Tue, 23 Dec 2014 12:12:32 -0500

Hi.

Since almost no one else seems to be doing so, I've made a
careful pass through 2141bis-08 looking for things it doesn't
seem to address  that have been discussed on this list or
elsewhere in the WG in the past.  Some of what I've found
appears to be just editorial.  I'll summarize those to the list
before Peter and I start making changes to see if anyone
disagrees and thinks they are substantive.  But there are some
substantive things that, IMO, deserve discussion and review.
This note is the first of a series that will address those, one
at a time and in separate threads.

This group of comments are entirely based on
draft-ietf-urnbis-rfc2141bis-urn-08.

Section 3.2 Namespace specific string syntax, doesn't seem
completely clear when p-, q-, or f-components are possible, nor
is it clear about any syntax issues within those components.  

Anyone have opinions about what should be said, or do Peter and
I need to take a guess at this?    If you do have opinions, text
would be ideal along with explanation/ justification.

  john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 23 Dec 2014 11:32:01 -0700

> at a time and in separate threads.

John, thanks for initiating these threads.

> 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.

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?

> nor

To date, we have simply pointed to RFC 3986 regarding the *syntax* of 
those components.

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.

Peter

-- 
Peter Saint-Andre
https://andyet.com/