Thanks Paul/Geoff!
I went ahead and re-added the "as defined by the standards or conventions of
its namespace" requested by Tom below as well.
I saw no problem in bringing that phrasing over from the original draft in
addition to the other changes previously mentioned.
Thanks,
-----Original Message-----
From: tom petch <daedulus@xxxxxxxxxxxxx>
Sent: Wednesday, August 30, 2023 4:53 AM
To: Paul Leach <pauljleach@xxxxxxx>; Geoff Huston <gih@xxxxxxxxx>; 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
From: last-call <last-call-bounces@xxxxxxxx> on behalf of Paul Leach
<pauljleach@xxxxxxx>
Sent: 28 August 2023 19:35
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".
<tp>
I think that many people will not have a concept of a namespace or of a
canonical form because outside the arcane world of computers, it rarely
applies. Names, people, places, often have variant spellings with no one
being regarded as 'the' one and humans have coped with that for centuries.
It is only with data stored on computers, with a need to compare, collate,
sort and such like, that a canonical form is needed and many namepaces do
not define adequately their canonical form. An RFC that gets it spot on is
RFC7950 YANG, which gives a canonical form for every construct, which, as it
is a DDL, is only common sense. But many name spaces do not bother.
I can interpret RFC4122 in that way but I can also misunderstand it. If it
said 'Convert the name to a canonical - as defined by the standards or
conventions of its name space - sequence of octets' it would be slightly
clearer but even then, those who have not needed to deal with the issue will
likely misunderstand.
For me, the canonical{!} example is host names and domain names, two similar
namespaces with different rules. differences which have caused many problems
over the years and which still do:-(
Tom Petch
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/
> nu.org%2Fsoftware%2Flibc%2Fmanual%2Fhtml_node%2FByte-Order.html&data=0
> 5%7C01%7C%7C14f189a754284205632608dba7f110a0%7C84df9e7fe9f640afb435aaa
> aaaaaaaaa%7C1%7C0%7C638288426034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=mIQmEa6HtWsw6sK0kGRbw8X6uB0LL30ewLnuqMQlsb8%3D&reserved=0
> [2]
> https://en.wi/
> kipedia.org%2Fwiki%2FCanonicalization&data=05%7C01%7C%7C14f189a7542842
> 05632608dba7f110a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638288
> 426034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xDqLukaRp5gdCS
> FzKzjue1H3kjzTRF%2FSabbV%2F6iS9z8%3D&reserved=0
> [3]
> https://en.wi/
> kipedia.org%2Fwiki%2FCanonical_form&data=05%7C01%7C%7C14f189a754284205
> 632608dba7f110a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63828842
> 6034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sm4JocW5hoZWh5XG
> 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.ietf.org/mailman/listinfo/uuidrev
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
