Re: [urn] Standardization of URN R component semantics

[[e-mail]]

"Hakala, Juha E" <[e-mail]> writes:
> RFC 8141 says in the end of clause 2.3.1 that
>
> r-components SHOULD NOT be used for URNs before their semantics have
> been standardized.
> 
> In order to proceed with our R-component implementation it is
> necessary to agree how such standardization can be done as efficiently
> as possible, and with minimum bureaucracy.
>
> Revising RFC 2483 would be a mistake, because it must be easy to add
> in the future both new R-components and additional parameters to
> existing components. A more flexible solution would be a new
> Registered R-components section to the IANA register of URN namespaces
> (https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml)
> Requests for new R-components and parameters could then be processed
> by the same group of experts which reviews the namespace registration
> requests. I believe we are more than capable of doing this. Compared
> with the review of URN namespaces review of R-component related
> requests should be easy.
> [...]
> Some R-components, such as I2C, will often be accompanied by
> parameters. We suggest that they should be separated by "&p=" from
> service requests, which in turn will begin with "s=". For instance, in
> order to receive metadata about the resource in Dublin Core format, an
> R component ?+s=I2C&p=DC might be used.

I'm glad to see this experiment.  And, yes, standardization is needed.
You haven't mentioned it, but the first step is establishing non-trivial
syntax for r-components.  RFC 8141 sec. 2.3.1 gives only the BNF

      r-component   = pchar *( pchar / "/" / "?" )

and implicitly requires that an r-component may not contain the sequence
"?=".

It looks like your work assumes that the r-component has the syntax

     name = value *( & name = value )

with "&", "?", and possibly "=" being forbidden in "name" and "value.
(This seems to be the same as HTTP URL query components, though I can't
find the reference right now.)

It looks like you need a registry for r-component names, with "s" being
registered to specify the resolver service that is requested,
referencing RFC 2483 for the allowed values.  (Does that become a new
registry?)

Each service value needs to have a specification for the names of its
operands, which RFC 2483 doesn't provide.

RFC 2483 describes what the output of the resolution operation is
abstractly, including data items and error conditions.  But since access
to a resolution service is not standardized, we can standardize how
return data items and error conditions will be encoded.

Dale