Subject: Guidance on I-D for alternate UUID representation

From: [email-masked]
Date: Tue, 9 Jul 2019 19:41:40 -0700

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

---

From: [email-masked]
Date: Wed, 10 Jul 2019 09:52:58 -0700

To pre-empt any redundant responses: I now have the information I need from responses off-list.

Thanks,

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