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

Thanks Dale and Peter for reviewing, line breaks have now been added!

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. 

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.

So my preference would be to leave the ABNF as is; the current registration text already mentions the sub-namespace entries need to be registered and that these will impose additional requirements on their associated sn-content. So the ABNF alone can't e.g. tell that "urn:thread:dataset:hello" is invalid, it's just a tool to guide the process.

If there's still a good reason to have the ABNF updated, please let me know. One option then is to avoid the ambiguity problem:

  urn-thread    = "urn:thread:" sub-namespace *( ":" sn-content )
  sub-namespace = 1*unreserved
  sn-content    = *( pchar / "/" )

It allows a single "label" and the rest is data. Then it's the responsibility of the particular registry entry to have a definition for the data (sn-content) which may include further detailing such as "act:hex:<hex-string>" which now all has become data. But this creates confusion/complexity of its own so I'd prefer not to do this, unless there's a good reason to.

Best regards
Esko

-----Original Message-----
From: Peter Saint-Andre <[email protected]> 
Sent: Wednesday, November 20, 2024 00:33
To: Dale R. Worley <[email protected]>; Esko Dijk <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [urn] Registration request for urn:thread:

On 11/19/24 12:57 PM, Dale R. Worley wrote:
> Esko Dijk <[email protected]> writes:
>> Also we've updated our registration request template based on the
>> review and to provide the reference to this online registry.
>> New template:
>> https://github.com/ThreadGroup/urn-thread-registry/blob/main/urn-registration-v1.txt
> 
> I'm OK with the concept.  As to the formatting of the template, I'd like
> to see the lines in urn-registration-v1.txt be wrapped.  As my browser
> displays that URL, each paragraph is one single line that wanders very
> far off to the right, and I suspect for other people it's the same.

Just FYI: if necessary, as team lead I clean up registration requests 
(placing line breaks after 72 characters per line) before I submit them 
to IANA.

> As to the syntax:
> 
>    urn-thread    = "urn:thread:" sub-namespace *( ":" sn-content )
>    sub-namespace = sn-label *( ":" sn-label )
>    sn-label      = 1*unreserved
>    sn-content    = *( pchar / "/" )
> 
> A thread URN consists of "urn:thread" followed by one or more sn-label's
> and then by zero or more sn-content's.  Note that one can't tell the
> difference between sn-label's and sn-content's by syntax, as both can be
> composed entirely of pchar's.  So splitting the sn-label's from the
> sn-content's requires additional information.  I suppose you might
> expect a parser to know all of the possible sub-namespace's, but that is
> difficult to maintain.
> 
> Also, colon is a pchar, so an sn-content can contain a colon.  That
> means that a series of multiple sn-content's cannot be parsed without
> additional information.
> 
> I think you may want to revise the syntax specification.

Agreed.

Peter


_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]