On Tue, 7 Jan 2014, Mark Andrews wrote: Thanks for the review Mark.
Section 3.1 has lots of factually incorrect rationals for encoding using base32. The DNS is capable of encoding binary data in labels up to 63 octets. I've got no problem with encoding, but if one intends to include rationalisations please make them factually correct.
I took those from draft-hoffman-dane-smime-01, Paul Hoffman and Jacob Schlyter believe these to be right as well? Can you explain what's wrong or perhaps write a replacement paragraph that would agree with you more? It's mostly there to explain why we did not end up using username._openpgpkey.domain.com and require base32 encoding.
There is no mention of how to encode LHS which exceed 63 octets when encoded using base32. Pack the left most labels or the right most labels?
Is that really a use-case we need to cover? How many _real_ +- 50+ LHS character email addresses do people use? I'm happy to document the limitation, a little more reserved for specifying tricks to go beyond. For example, http://tools.ietf.org/html/rfc6763 mentions this limit too in context of UTF8,unicode,Kanji without defining anything to extend this limit.
There is no mention of how to normalise LHS prior to base32 encoding.
That was discussed offline, but you are right in that the result of that discussion is missing. Since there seems to be great variety in how SMTP servers normalise the LHS, we did not want to enforce our one normalisation.
Are "Hugh" and "hugh" the same?
That really depends on the SMTP server implementation, the OS it runs on, the email client used by the sender, etc.
Should "hugh" and "hugh+xxx" be treated the same?
I don't think so? The "+" sign as magic "this is the same user as" is also not a feature supported by all SMTP servers or specified in a standard, correct? And people might want to use different keys for paul+personal versus paul+ietf.
It should be possible to specify normalisation rules and store them at _openpgpkey.
But those rules could change if the SMTP implementation changes? So, this document is leaving these as unclear as whether your email will arrive at all or not based on the presence or absence of normalisation rules of the SMTP server.
It might be useful to suppress the padding at the end of base32 encoded strings. We already do similar suppression with NSEC3 records.
Unlike NSEC3 we will see some interaction with userland tools and humans that will use stock base32 that produces the padding. So I have a slight preference to stick with the output generated by standard base32 code in the hope that it will be less confusing to users and developers. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
