[urn] Re: Registration for the TEI: URN identifier
Peter Saint-Andre <[email protected]> Fri, 6 Mar 2026 16:43:46 -0700
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <[email protected]> |
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 [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? 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ urn mailing list -- [email protected] To unsubscribe send an email to [email protected]