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

> On 7 Mar 2026, at 00:43, Peter Saint-Andre <[email protected]> wrote:
> 
> Hej Olle!
Hej Peter! Good to hear from you!

> 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 [email protected] 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?

Thank you for good and very helpful feedback. We will update and come back to you soon.
> 
> Note that I have not taken the time to read the TEA spec. Perhaps some of my questions are answered there.
I think the application needs to include the basics, so there should be no need. But if you have time it’s
a cool solution - automation of the software supply chain in the light of the EU Cyber Resilience Act.

Have a nice weekend!
/O
> 
> 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 -- [email protected]
>> To unsubscribe send an email to [email protected]
> 

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