Smith,
Probably worth talking about. CUPS has long used the version 3 (name-based) UUID format, and programs like "uuidgen" and the corresponding DCE APIs (uuid_generate, uuid_generate_random, uuid_generate_time) are limited to version 1 (time-based) or 4 (random) UUIDs. In most cases I don't think there is a huge need for locality or time sequencing, but I can see some benefit in clustered configurations for job accounting (for example).
The new version 8 ("vendor/experimental") format would allow for an IPP-specific UUID, e.g.:
H = SHA256("FQDN:PORT:PRINTER-ID")
H_upper = bytes 0-4 of H
H_middle = bytes 14-17 of H (with middle bits masked for ver)
H_lower = bytes 29-31 of H (with top bits masked for var)
ver = 1000b
var = 10b
doc-num = document-number or 0 for a Job/Printer
job-id = job-id or 0 for Printer
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H_upper |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H_middle | ver | H_middle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| H_lower | doc-num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| job-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For example, if a Printer has a FQDN of "printer.example.com <http://printer.example.com/>", is listening on the standard IPP port of 631, and has a printer-id of 1, the SHA-256 hash would be "af5ba1f02b24eccde959e974be6cf32b49d4ae74ec4946a63ce5cce79e1d43dd", yielding the following prefix for the UUID:
urn:uuid:af5ba1f0-f32b-89d4-1d43-dd
The printer-uuid would be:
urn:uuid:af5ba1f0-f32b-89d4-1d43-dd0000000000
The job-uuid for job-id 42 would be:
urn:uuid:af5ba1f0-f32b-89d4-1d43-dd000000002a
The document-uuid for document 3 of job 42 would be:
urn:uuid:af5ba1f0-f32b-89d4-1d43-dd030000002a
A similar scheme could be developed for system-uuid and resource-uuid, and if we wanted to be able to identify specific types of objects we could add a type field (so you could identify the type of object by the UUID value).
Anyways, worth discussing...
> On Nov 21, 2023, at 11:09 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org> wrote:
>> Hi Ira,
>> I read the draft, and it is interesting. I was wondering about how you thought its publication might affect the use of UUIDs in IPP? Perhaps we ought to discuss this in a future IPP call?
>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>>> On Nov 7, 2023, at 1:10 PM, Ira McDonald via ipp <ipp at pwg.org> wrote:
>>>> CAUTION: External Email Hi,
>>>> Major update to IETF standardized UUID formats (RFC 4122bis) just approved for RFC publication by IESG today.
>>>> Cheers,
>> - Ira
>>>> Ira McDonald (Musician / Software Architect)
>> Chair - SAE Trust Anchors and Authentication TF
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Co-Chair - TCG Metadata Access Protocol SG
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music / High North Inc
>>http://sites.google.com/site/blueroofmusic>>http://sites.google.com/site/highnorthinc>> mailto: blueroofmusic at gmail.com>> (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>>>> ---------- Forwarded message ---------
>> From: The IESG <iesg-secretary at ietf.org>
>> Date: Tue, Nov 7, 2023 at 12:12 PM
>> Subject: [Uuidrev] Protocol Action: 'Universally Unique IDentifiers (UUID)' to Proposed Standard (draft-ietf-uuidrev-rfc4122bis-14.txt)
>> To: IETF-Announce <ietf-announce at ietf.org>
>> Cc: The IESG <iesg at ietf.org>, <draft-ietf-uuidrev-rfc4122bis at ietf.org>, <mcr+ietf at sandelman.ca>, <rfc-editor at rfc-editor.org>, <superuser at gmail.com>, <uuidrev-chairs at ietf.org>, <uuidrev at ietf.org>
>>>>>> The IESG has approved the following document:
>> - 'Universally Unique IDentifiers (UUID)'
>> (draft-ietf-uuidrev-rfc4122bis-14.txt) as Proposed Standard
>>>> This document is the product of the Revise Universally Unique Identifier
>> Definitions Working Group.
>>>> The IESG contact persons are Murray Kucherawy and Francesca Palombini.
>>>> A URL of this Internet-Draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/>>>>>>>>>> Technical Summary
>>>> This specification defines the UUIDs (Universally Unique IDentifiers)
>> and the UUID Uniform Resource Name (URN) namespace. UUIDs are also
>> known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits
>> long and is intended to guarantee uniqueness across space and time.
>> UUIDs were originally used in the Apollo Network Computing System and
>> later in the Open Software Foundation's (OSF) Distributed Computing
>> Environment (DCE), and then in Microsoft Windows platforms.
>>>> This specification is derived from the DCE specification with the
>> kind permission of the OSF (now known as The Open Group).
>> Information from earlier versions of the DCE specification have been
>> incorporated into this document. This document obsoletes RFC4122.
>>>> Working Group Summary
>>>> The document represents a strong concurrence of a many individuals, including
>> many from outside the IETF community who maintain running code.
>>>> Document Quality
>>>> Yes there are a number of implementators involved, and many have implemented
>> the changes.
>>>> The ITU-T and the ISO published documents similiar to RFC4122 at the time,
>> but they have not responded to this BIS process.
>>>> Personnel
>>>> The Document Shepherd for this document is Michael Richardson. The
>> Responsible Area Director is Murray Kucherawy.
>>>> --
>> Uuidrev mailing list
>>Uuidrev at ietf.org>>https://www.ietf.org/mailman/listinfo/uuidrev>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
________________________
Michael Sweet