Smith,
> On Nov 11, 2020, at 8:44 AM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>>> ...
>>> • "client-key" (type2 keyword) - REQUIRED
>>>> I think we also need to explicitly allow non-registered reverse-DNS identifiers since that is what macOS/iOS bundle identifiers and Java class naming uses, with a note about that. The goal should be to have a stable identifier that you don't have to do fuzzy matching on (like happens with User-Agent in the HTTP world).
>> No objections, but if so would that require a shift in the syntax definition to be (type2 keyword | name(MAX))?
No, it can stay as a type2 keyword. Much like we do for the media keywords, this client-key member attribute can have registered values and (registered or unregistered) vendor values that follow a defined syntax.
The goal here is to have unique identifiers for different software components on the Clients. On macOS and iOS those identifiers are reverse-DNS things like "com.apple.pages" and "org.mozilla.firefox". Java has a similar convention, while Windows seems to use a keyword-friendly format of the form "[Vendor or Application].[Component].[Version]":
https://docs.microsoft.com/en-us/windows/win32/shell/fa-progids
I really don't think we can expect Clients to do any useful mapping of application IDs, nor can we expect application developers to register their software with the PWG. Rather, I think having an up-to-date registry for operating system names (and maybe major IPP clients like CUPS) along with a liberal syntax for (unregistered) application identifiers ("local_foo.bar.bla" with no version information) will be about the best we can expect Clients to support.
________________________
Michael Sweet