> On 28 Aug 2023, at 8:56 am, Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> wrote: > > I agree with the previous email's points. > > Personally, I have never been a fan of "canonical" verbiage in the original document, so I suggest we remove it from the text. > From what I can see "canonical" usage is just a fancy way of saying "Select a Name value formatted as per the underlying specs usual representation format". Sources: [1][2][3]. > > For example in UUIDv3, with "canonical" removed, the text would say: >> UUIDv3 values are created by computing an MD5 [RFC1321] hash over a given name space value concatenated with the desired name value after both have been converted to a sequence of octets in network byte order. > > Then I can add a line above the Appendix callout for Namespaces with guidance on how to select said name value and representation from an underlying spec when there are many to choose from. I agree with this proposal > >> Information around selecting a desired name value's representation/conveyance format within a given name space can be found in section 6.5, "A note on names". >> Some common namespace values have been defined via Appendix A. > > Then repeat this for UUIDv5 and remove "canonical" from the v8 callout in 6.5. Again, I agree with this. > > Finally, update the line about names and namespaces being equal to state to include a line about the representation format. >> The UUIDs generated at different times from the same name (using the same name representation/conveyance format) in the same namespace MUST be equal. again, this looks suitable for me kind regards, Geoff > > Off topic: I have opened an item #137 on the tracker to convert all "name space" to "namespace" since it is bugging me that the original document had both defined when the one with no space seems to be the better option. > > Define "canonical": > [1] https://www.gnu.org/software/libc/manual/html_node/Byte-Order.html > [2] https://en.wikipedia.org/wiki/Canonicalization > [3] https://en.wikipedia.org/wiki/Canonical_form > > -----Original Message----- > From: Geoff Huston <gih@xxxxxxxxx> > Sent: Monday, August 28, 2023 11:17 AM > To: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> > Cc: uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx > Subject: Re: [Last-Call] Dnsdir telechat review of draft-ietf-uuidrev-rfc4122bis-10 > > Hi Kyzer, > > Thank for your clarification here. > > It looks like you have taken the text in section 4.3 of RFC4122 > > "Convert the name to a canonical sequence of octets (as defined by the standards or conventions of its name space); put the name space ID in network byte order.” > > and rephrased it in this draft. > > My question remains - what is a “canonical” sequence of octets? Or even its opposite - what is a sequence of octets that is NOT “canonical”? > > In a standards document it seems reasonable to ask for extremely clear specifications, and I just don’t understand what you are getting at with the use of the term “canonical” here. > > regards, > > Geoff > > > > > >> On 28 Aug 2023, at 6:39 am, Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> wrote: >> >> Geoff and Michael, >> >> The entire sub-section in 6.5 titled "a note on names" was added in draft-08 to explicitly provide context around name usage, selection and provide a few examples from each of the called out dependencies. >> >> I can add a reference so the earlier sections that state "canonical sequence of octets in network byte order" have a link to 6.5's sub-section letting folks know where to go to understand what that means? >> >> Also, to note, I did not pick "canonical sequence of octets in network byte order" this is from the original specs; I am open to a different verbiage to describe this. >> >> Thanks, >> >> -----Original Message----- >> From: Michael Richardson <mcr+ietf@xxxxxxxxxxxx> >> Sent: Saturday, August 26, 2023 2:59 PM >> To: Geoff Huston <gih@xxxxxxxxx>; dnsdir@xxxxxxxx; >> draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx; >> uuidrev@xxxxxxxx >> Subject: Re: [Last-Call] Dnsdir telechat review of >> draft-ietf-uuidrev-rfc4122bis-10 >> >> >> Geoff Huston via Datatracker <noreply@xxxxxxxx> wrote: >>> "Section 5.3, 5.5 and 6.5 refer to "a canonical sequence of octets >>> in network byte order". It is not specified what that canonical >>> sequence is nor is there a reference to a document that specifies the >>> canonical sequence for any of the name spaces." >> >> I think that we generally expect people to use a string, literally, "example.com" >> and I think that the words "network byte order" might be what confuses. >> >> Maybe some people would use RFC1035 sequence of labels format though. >> >> In the end, it doesn't matter as along as the entity creating the name-based UUID says what they did. Still, I agree that it would be good if we gave more advice here. >> >> Are there some references you would suggest here, assuming that we just want a string. >> >> >> -- >> Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
