I am happy with the additional test in the note on namespaces Geoff > On 29 Aug 2023, at 12:16 pm, Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> wrote: > > Geoff, Paul, Michael, > > I have made the changes as per this discussion thread and the PR is open for > review. > https://github.com/ietf-wg-uuidrev/rfc4122bis/pull/138/files > > Let me know if there are any further changes to be made by commenting in > this thread or adding a comment to the PR. > I plan to submit this Friday so the draft can stay on track for the 9/7 > telechat. > > Thanks! > > -----Original Message----- > From: Paul Leach <pauljleach@xxxxxxx> > Sent: Monday, August 28, 2023 8:25 PM > To: Geoff Huston <gih@xxxxxxxxx> > Cc: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx>; uuidrev@xxxxxxxx; > dnsdir@xxxxxxxx; draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; > last-call@xxxxxxxx > Subject: RE: [dnsdir] [Last-Call] Dnsdir telechat review of > draft-ietf-uuidrev-rfc4122bis-10 > > Geoff -- > > I also prefer the latter, because it gives guidance for implementing new > namespaces. > > Best, > Paul > > -----Original Message----- > From: Geoff Huston <gih@xxxxxxxxx> > Sent: Monday, August 28, 2023 12:53 PM > To: Paul Leach <pauljleach@xxxxxxx> > Cc: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx>; uuidrev@xxxxxxxx; > dnsdir@xxxxxxxx; draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; > last-call@xxxxxxxx > Subject: Re: [dnsdir] [Last-Call] Dnsdir telechat review of > draft-ietf-uuidrev-rfc4122bis-10 > > Hi Paul, > > I found the use of the term "canonical" without an explicit definition of > its interpretation in the context of this specification to be unclear to me, > and I was wondering what was meant. > > Ether the document can avoid using this this term as proposed by Kyzder, or > include an explanation of the term along the lines of your text below, > namely "A canonical sequence of octets is one that conforms to the > specification for that name form's canonical representation. A name can have > many usual forms, only one of which can be canonical. Implementers of _new_ > name spaces for UUIDs need to use the specification for the canonical form > of names in that space, or define such a canonical for the name space if it > does not exoist" > > I prefer the latter personally, but I can live with either! > > kind regards, > > Geoff > > > > > > > > > > >> On 28 Aug 2023, at 12:35 pm, Paul Leach via dnsdir <dnsdir@xxxxxxxx> > wrote: >> >> I'm the author of those words in 4122, and I meant "canonical" in the > ordinary English sense. Some sample definitions: >> >> Wikipedia: >> The adjective canonical is applied in many contexts to mean > 'according to the canon' - the standard, rule or primary source that is > accepted as authoritative for the body of knowledge or literature in that > context. >> >> Dictionary.com: >> relating to, established by, or conforming to a canon or canons >> >> AED (fourth sense): >> Conforming to orthodox or recognized rules >> >> Or, as it said in section 4.3 of RFC 4122 "as defined by the standards or > conventions of its name space". >> >> So, to answer Geoff's question: a canonical sequence of octets is one that > conforms to the specification for that name form's canonical representation. > A name can have many usual forms, only one of which can be canonical, so it > isn't just a fancy way of saying to use the "usual representation format". >> >> No amount of increasing the specificity for the UUID versions defined in > UUID-REV will replace the need to tell implementers of _new_ name spaces > that they need to use the specification for the canonical form of names in > that space. (Or to define one for the name space if it doesn't exist.) For > example, a new text string based namespace would have to specify the > character encoding (e.g., ASCII, EBCDIC, UNICODE), what to do about cases, > etc. >> >> Paul >> >> >> -----Original Message----- >> From: Uuidrev <uuidrev-bounces@xxxxxxxx> On Behalf Of Geoff Huston >> Sent: Monday, August 28, 2023 11:02 AM >> To: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> >> Cc: uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; >> draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx >> Subject: Re: [Uuidrev] [Last-Call] Dnsdir telechat review of >> draft-ietf-uuidrev-rfc4122bis-10 >> >> >> >>> 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/. >>> g%2F&data=05%7C01%7C%7C1cca11e012164c3a72bb08dba8006c08%7C84df9e7fe9f >>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638288491994497116%7CUnknown%7CTWFpbG >>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C3000%7C%7C%7C&sdata=hF71vSX2nCJ8pyDwu2tuy3sjs8DhDO0Vy13LW7avvT4 >>> %3D&reserved=0 >>> nu.org%2Fsoftware%2Flibc%2Fmanual%2Fhtml_node%2FByte-Order.html&data= >>> 0 >>> 5%7C01%7C%7C14f189a754284205632608dba7f110a0%7C84df9e7fe9f640afb435aa >>> a >>> aaaaaaaaa%7C1%7C0%7C638288426034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIj >>> o >>> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C >>> % >>> 7C%7C&sdata=mIQmEa6HtWsw6sK0kGRbw8X6uB0LL30ewLnuqMQlsb8%3D&reserved=0 >>> [2] >>> https://en.w/ >>> i%2F&data=05%7C01%7C%7C1cca11e012164c3a72bb08dba8006c08%7C84df9e7fe9f >>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638288491994497116%7CUnknown%7CTWFpbG >>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C3000%7C%7C%7C&sdata=x6lFVqqG%2F75SpzFoVyVywzBYXwounqF6Sgz2s2N4z >>> tc%3D&reserved=0 >>> kipedia.org%2Fwiki%2FCanonicalization&data=05%7C01%7C%7C14f189a754284 >>> 2 >>> 05632608dba7f110a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63828 >>> 8 >>> 426034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu >>> M >>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xDqLukaRp5gdC >>> S >>> FzKzjue1H3kjzTRF%2FSabbV%2F6iS9z8%3D&reserved=0 >>> [3] >>> https://en.w/ >>> i%2F&data=05%7C01%7C%7C1cca11e012164c3a72bb08dba8006c08%7C84df9e7fe9f >>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638288491994497116%7CUnknown%7CTWFpbG >>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C3000%7C%7C%7C&sdata=x6lFVqqG%2F75SpzFoVyVywzBYXwounqF6Sgz2s2N4z >>> tc%3D&reserved=0 >>> kipedia.org%2Fwiki%2FCanonical_form&data=05%7C01%7C%7C14f189a75428420 >>> 5 >>> 632608dba7f110a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6382884 >>> 2 >>> 6034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >>> I >>> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sm4JocW5hoZWh5X >>> G >>> Ab1%2FakeVGDEgichc6P5v0tnmkLY%3D&reserved=0 >>> >>> -----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 >>>> >>>> >>>> >>>> >>> >> >> -- >> Uuidrev mailing list >> Uuidrev@xxxxxxxx >> https://www.i/ >> etf.org%2Fmailman%2Flistinfo%2Fuuidrev&data=05%7C01%7C%7C1cca11e012164 >> c3a72bb08dba8006c08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63828 >> 8491994497116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu >> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x5d9UAOlIU1ex >> UduHM0EMYmxgF4iDKFkatXoI3QiNkk%3D&reserved=0 >> >> -- >> dnsdir mailing list >> dnsdir@xxxxxxxx >> https://www.i/ >> etf.org%2Fmailman%2Flistinfo%2Fdnsdir&data=05%7C01%7C%7C1cca11e012164c >> 3a72bb08dba8006c08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638288 >> 491994497116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM >> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FLiLn2B1I0bwyA >> 1devvYfqQQ85vlW4n7IktdIOpnlP4%3D&reserved=0 > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
