Guidance on I-D for alternate UUID representation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greetings IETF,

I have designed an alternate representation for the UUID, for the purpose of being able to stuff valid (per RFC 4122) UUIDs into grammars (such as XML NCName) that do not ordinarily accommodate them. I have two implementations[1,2] which I currently use in applications. As you will see in the existing documentation, I designed these representations (a case-sensitive Base64 and case-insensitive Base32) specifically to act as identifiers in data formats and network messages where existing constraints on the token grammar prohibits the conventional representation.

I cite RFCs 4122 and 6920 as precedent that such a specification belongs with the IETF, however at this juncture I am unsure as to which active working group best reflects the content. I understand that individual submissions need a sponsor, so I am also asking how one goes about getting one.

Incidentally, the identifiers look like this: Ezr1_nC-VgBxKid343wq9K, and this: ez26x7hbpswabysuj3x4n6cv5k (for the UUID cebd7f9c-2f95-4801-ac4a-89ddf8df0abd).

Thanks in advance,

1) https://metacpan.org/pod/Data::UUID::NCName
2) https://www.rubydoc.info/gems/uuid-ncname/0.2.2

--
Dorian Taylor
Make things. Make sense.
https://doriantaylor.com

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux