[urn] Re: Registration for the TEI: URN identifier

Olle E Johansson <[email protected]> writes:
> We did move the types of PURL into a separate spec, so that's probably
> a good idea since we will add new types as we find them.

The advantage of putting an umbrella syntax in the registration is that
you don't have to update the registration to add a new <type>, just
endure the syntax of the new type conforms to the umbrella syntax.

>> However, there is this point in RFC 8141:
>> 
>>      Unless the registration explicitly describes the semantics of
>>      r-components, q-components, and f-components in the context of
>>      this URN namespace, those semantics are undefined.
>> 
>> Looking at the web page, I see this example:
>> 
>>    urn:tei:purl:cyclonedx.org:pkg:pypi/[email protected]?extension=whl&qualifier=py3-none-any
>
> The qualifiers here are qualifiers to the PURL that starts with PKG:,
> not to the URN.  We may want to clarify that.

I was looking further into that.  It turns out that the uses of "?" in
a URN are more restricted than in URIs generally, and I assume that
PURLs allow the general URI usage.

See sections 2 and 2.3 of RFC 8141.  Basically, there are *three*
add-on components to URNs:  (in order:) the r-component, written
"?+..."; the q-component, written "?=...", and the f-component,
written "#...".  The r-component is defined generically for all URNs
and I think we can safely ignore discussing it.  The f-component is
entirely parallel to the fragment identifier of generic URIs.

The q-component is intended to semantically parallel the query
component of URIs, and to be transcribed into the query component of a
URL that a URI resolves into:

   Consider the hypothetical example of passing parameters to an
   application that returns weather reports from different regions or
   for different time periods.  This could perhaps be accomplished by
   specifying latitude and longitude coordinates and datetimes in the
   URN's q-component, resulting in URNs such as the following.

      urn:example:weather?=op=map&lat=39.56
         &lon=-104.85&datetime=1969-07-21T02:56:15Z

   If this example resolved to an HTTP URI, the result might look like:

      https://weatherapp.example?op=map&lat=39.56
         &lon=-104.85&datetime=1969-07-21T02:56:15Z

I don't see the TEI specification talking about this, but you speak as
if TEI intends the "query part" of a TEI URN to be transcribed in this
manner.  So there's no problem with the semantics.

In order to align the TEI registration with RFC 8141, we can specify
that the parameter of the q-part is to be transcribed into the query
part of a resolved URL.  In the case of

    urn:tei:purl:cyclonedx.org:pkg:pypi/[email protected]?=extension=whl&qualifier=py3-none-any

it is resolved into

    pypi/[email protected]?extension=whl&qualifier=py3-none-any

Note that the "?=" has been changed into "?".

There is, however, a gotcha:  The syntax of "query" (the part after
the "?") for URIs is

   query         = *( pchar / "/" / "?" )

but the syntax of q-component is

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

That is, the q-component can't be empty and must start with a pchar.

For most uses, an empty query part is likely equivalent to the query
part being absent.  So I don't think we have to accommodate that case
in the URN definition.

But we do have the strange corner cases of the desired query part
starting with "?" or "/".  Both of these are valid URLs:

    http://exaple.com/foo??
    http://exaple.com/foo?/

whereas these are not valid URNs:

    urn:example:foo?=?
    urn:example:foo?=/

It seems to me that there are three possible solutions:

1) Define a pchar padding character at the beginning of the
q-component that is dropped when it is transcribed:

    urn:example:foo?=x?
    urn:example:foo?=x/

This is ugly but completely general.

2) If the first character of the q-component is "?" or "/",
percent-encode it, on the assumption that the ultimate interpreter of
the URL will interpret the percent-encoding the same way as the plain
character:

    urn:example:foo?=%3F
    urn:example:foo?=%2F

3) Forbid the situation:  In the TEI URN specification for type Purl,
say that if the PURL contains a query component, it must be nonempty
and may not start with an (un-encoded) "?" or "/".

At the moment, (3) combined with (2) seems to me to be the best
solution.

> The URN syntax checkers
> I have tested with found no problem with this syntax, but they may not
> be correct.

Yes, it looks like they aren't enforcing sec 2 of RFC 8141:

   The question mark character "?" can be used without percent-encoding
   inside r-components, q-components, and f-components.  Other than
   inside those components, a "?" that is not immediately followed by
   "=" or "+" is not defined for URNs and SHOULD be treated as a syntax
   error by URN-specific parsers and other processors.

Dale

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