/.well-known/resolver
Please confirm that:
- [ X] You have read and understood the requirements for registration.
- [ X] You have checked the registry and found no current value that meets your needs.
- [X ] Your specification reference URL is stable; ideally, managed by a widely-recognised standards development organisation (e.g., published as an RFC). Otherwise, please give additional information.
If so, please enter the details of the well-known URI below:
- URI suffix:
resolver - Change controller: ISO/IEC JTC1, SC31
- Specification document(s): ISO/IEC 18975:2024 Information technology — Automatic identification and data capture techniques — Encoding and resolving identifiers over HTTP
Any additional information (this will not be included in the registry)?
The suffix gs1resolver registered some time ago refers to the specific GS1 standard for resolving its identifiers. (Although the original reference in that registration is still OK, a better one would now be https://ref.gs1.org/standards/resolver/).
The ISO/IEC standard (published November 2024) is a more general standard (to which the GS1 standard conforms). The relevant section of the ISO/IEC standard says:
5.2 LinkType parameter
This document builds on RFC 9264[13] to define a type of resolver. As well as being able to return a linkset, a conformant resolver will be able to redirect to any of the links in the set associated with the identified item. A request to the resolver is formed by setting the value of the linkType parameter to the desired link relation type and appending it to the HTTP URI that identifies the item. The resolver makes a best effort to select a match for the requested link relation type from the links available in the linkset and redirect to it immediately. Link relation types, other than those listed in the IANA registry[9] defined by RFC 8288[12], should be expressed as CURIEs[4]. Annex D provides worked examples of how an identified item can be queried for specific information.
6 Online considerations
All internet domain names have complete sovereignty over their URI space. Applications should not assume that any URI that conforms to either the structured path or query string approach has necessarily been minted for use as described in this document. It is up to individual applications to decide whether the context in which the URI is found is sufficient reason to treat it as anything other than an opaque identifier. This is likely to be the case when encoded in an AIDC data carrier attached to an object, but it cannot be guaranteed.[2] However, whether a server operates as a resolver can be determined with confidence. Servers that are programmed to respond with a linkset in response to an appropriate query, and to process the linkType parameter, shall include a JSON file at /.well-known/resolver (the use of /.well-known is defined in RFC 5785[11]). This is known as the resolver description file.
Hi Phil,
Apologies for the delay; I'm consulting with the IESG about whether that reference can qualify as 'publicly available' and should hear back soon.
To process this registration request, I will need a copy of the specification; can you provide one?
My initial feedback is that 'resolver' is an extremely generic term, whereas this protocol seems to be fairly specific. Have you considered using a correspondingly specific name, e.g., gs1resolver?
Thanks Mark.
I'm not allowed to share the doc publicly (you kow ISO...). The text above is a screenshot of the original which is as much as I can share openly. I can send you a copy privately.
As for making it more specific, how about iso-iec-18975-resolver or just 18975-resolver? I can't change the actual ISO/IEC standard without going through the whole process but the specific reference in the suffix here would be clear enough I'd hope?
On reflection, I'm planning a different approach, namely, once other closely related work I'm now doing with AIM and RAIN is complete, I'll make a W3C Member Submission which will create an open reference. So, for now, leave this on the shelf. Apologies for the noise.
No worries. Those names are better, FWIW.