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

[Peter Saint-Andre <[e-mail]>]

Hej Olle! Thanks for submitting this request for community review.

Here are some comments...

Under the "Registrant" section, in general we prefer role email 
addresses, such as [e-mail] or whatever.

The syntax definition is lacking in detail (e.g., ABNF would be nice). 
Specifically:

1. <type> - What are the allowable characters? How long can the <type> 
be? And, under the "Assignment" section, are the types assigned by TC54 
or through some other method? Can software/product vendors create their 
own types? The "Assignment" section seems to hint that this is the case.

2. <domain-name> - There are always complexities with domain names. Can 
you reference a syntax definition from an RFC? Do you allow 
internationalized domain names? Etc.

3. <unique-identifier> - What exactly does this construct uniquely 
identify: a product, a SKU, a "software transparency artefact" (whatever 
that is)? Here again, what are the allowable characters, length, etc.? 
The fact that the syntax "is set by the type field" makes it all the 
more important to clarify how type fields are assigned and defined, 
since if that process is not well managed then the <unique-identifier> 
could be just about anything.

Please note that, as specified in RFC 8141, URN assignment needs to be a 
managed process. It's not really satisfactory to say "well if you fiddle 
this `type` bit over here then the syntax of that `unique-identifier` 
bit over there could totally change and we have no idea what the end 
result might be". This is especially concerning if vendors can roll 
their own.

Although the "Resolution" section says that resolution doesn't apply, 
the "Purpose" section indicates that TEI URNs will enable clients to 
discover API services via a GUI or a QR code. This talk of discovery 
makes it sounds to me like resolution is happening somewhere in the 
overall system. Could you please clarify?

The "Interoperablity" section mentions encoding formats. What are these 
and how are they to be used in the context of the TEI system? What are 
the implications of these encoding formats for the syntax definitions?

Note that I have not taken the time to read the TEA spec. Perhaps some 
of my questions are answered there.

Peter

On 3/3/26 4:18 AM, Olle E Johansson wrote:
> Hi!
> 
> The OWASP work with an API for automation of supply chain artefacts, like SBOMs, VEX files and other attestations, is reaching version 1 and we will start the formal standardisation work within ECMA International TC54, task group 1, which is tasked with standardisation of the Transparency Exchange API (TEA).
> 
> In TEA, a customer will get a product identifier from the vendor, either on the outside of a package or within the product itself, to be able to discover API services and access documents for a given product and version.
> 
> I attach a PDF and markdown version of our application. Looking forward to your feedback!
> 
> Best regards,
> /Olle
> 
> 
> _______________________________________________
> urn mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]