[urn] Re: Registration request for urn:thread:

[[e-mail]]

Esko Dijk <[e-mail]> writes:
> On the syntax specification: the ABNF was introduced here just as a
> guideline to people designing a new entry for the registry, and the
> maintainers to check proposed new entries against. It wasn't intended
> for implementing a generic parser that could decompose any urn:thread
> item. 

The requirement for registration is that there be a syntax
specification, so that one can say a URN does or does not conform to the
specification.  There's no rule that the syntax specification has to be
unambiguous as a grammar.

OTOH, syntax specifications are usually expected to be tools for
understanding the conceptual structure of the namespace.  So if the
grammar is ambiguous, it would be informative to the reader to add a
note explaining how parsing is expected to be done in practice.

Relative to that desideratum,

> Still, some form of parsing is of course needed and maybe future use
> cases will need more generic parsers. Normally (today) a parser would
> be looking for a specific URN only or a subset of URNs. E.g. all the
> urn:thread:dataset:* ones for an app that configures Thread datasets,
> or all the urn:thread:pc:* ones for an app that allows passcode entry
> by QR code.  If we would write/need a generic parser for all items, it
> would have the list of sub-namespaces (i.e. registry items)
> implemented inside it, so it could still distinguish between 
>
> 1) valid-syntax URN (using known sub-namespace), 
> 2) valid-syntax URN (but unknown sub-namespace), or 
> 3) invalid-syntax URN. 
>
> I don't see any need or use case for parsing the sub-namespace
> unambiguously from a given 'thread' URN for cases where the
> sub-namespace is *not* in the registry -- as the code doing this
> parsing would anyway not know how to handle these, it would all fall
> into bucket 2)! It doesn't matter for this case if the parser would
> parse part of the sn-content as an sn-label, or vice versa parse a
> part of the sn-content as an sn-label.

I will note that in practice, maintaining a generic parser that needs to
know the current registrations is difficult in practice.  OTOH as you
say, you don't expect any uses where one needs to parse an arbitrary
thread URN, and it's easy to have a parser that handles only a defined
and unchanging subset of the URNs based on specific knowledge of that
subset.

Here is one point you should consider:  if "a:b:c" is registered as a
sub-namespace, is there a rule that "a:b:c:d" must not be registered as
a sub-namespace?  That is, even if the parser knows the namespaces in
question, the registration as written does not ensure that the parser
can determine unambiguously where the namespace ends.  In particular,
"urn:thread:a:b:c:d" is ambiguous whether (1) the sub-namespace is
"a:b:c:d" and there is no sn-content, or (2) the sub-namespace is
"a:b:c" and the sn-content is "d".

That can be resolved by either constraining that no registered
sub-namespace can be an extension of another registered sub-namespace,
or by constraining that, for any registered sub-namespace, any further
registered sub-namespaces must be distinguishable from possible
sn-content in some way.

As I said earlier in this message, resolving this is not required for
namespace registration, but I strongly suggest that you settle on a
resolution and document it in the registration.  That will be for the
readers' benefit and also will help you avoid getting tangled in syntax
difficulties later.

Dale