Re: [urn] Standardization of URN R component semantics

["Hakala, Juha E" <[e-mail]>]

Hello Dale, 

see comments below (marked with ***). 

-----Alkuperäinen viesti-----
Lähettäjä: Dale R. Worley <[e-mail]> 
Lähetetty: perjantai 10. maaliskuuta 2023 18.38
Vastaanottaja: Hakala, Juha E <[e-mail]>
Kopio: [e-mail]; Ilva, Jyrki T <[e-mail]>; Pietarila, Emma S S <[e-mail]>; Hyvönen, Nina <[e-mail]>
Aihe: Re: [urn] Standardization of URN R component semantics

"Hakala, Juha E" <[e-mail]> writes:
>
> [...]
> 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 "?=".

*** Having two R-components added to the same URN will not be supported in our resolver, and in my opinion we should consider disallowing such practice explicitly. 

After discussing the issue we have decided not to allow more than one operand/parameter in the same R-component in our resolver.  Is this something that should also be generally disallowed?  ***

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

*** Using HTTP URL query syntax in the R component is a simple solution which seems to provide all the functionality needed. ***

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?)

*** There are three reasons why a new registry is required: 
- RFC 2483 does not cover all services needed,
- it is not extensible (except via writing a new RFC), and 
- RFC 2483 does not specify service parameters/operands (such as specifying the format of the metadata required). 

RFC 2483 assumed that the metadata format would be URC (Uniform Resource Characteristics). It was a short-lived IETF idea to develop a generic metadata format, which was never implemented (Dublin Core serves a similar function). In practice, it must be possible to specify the format in which metadata should be delivered. ***  

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

*** I suppose your operand and my parameter are more or less the same thing. For the time being, the only service that IMO definitely must have operands/parameters is I2C, metadata request. Further discussion may be required for some other services; for instance, do we need a separate resolution service for requesting archive URLs, or is it better to specify this functionality as an operand to the generic URL request service. Resolver developers may have an opinion on this. ***  

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.

*** Deutsche Nationalbibliothek resolver has already an API (see https://api.nbn-resolving.org/sandbox/v2/) As a part of the EU FAIRCORE4EOSC project we shall investigate the possibility of adding an API to our resolver as well. Whether it is possible to agree on a common API I don't know. But if so, such API might be a good place for specifying protocol messages and error conditions related to data exchanges. *** 

Best regards,

Juha

Dale