Hi Stephen, > The tl;dr version is: once a revision addresses the > substantive issues raised as per below, taking into > account reactions to this summary, and we have a chance to > take a quick look at -08 (I'll extend the LC to the date > of the -08 version plus one week), then if no new > substantive issues arise, I think we have rough consensus > to go forward with this experiment (and others to come) > and let the IESG review the document. Thanks for producing this summary and these suggestions, with specific sections of text to be added, which gives a clear picture of what we're discussing. I was initially concerned that your additions, and the general process of updating the drafts to reach consensus, might have made the document become an unruly patchwork, but I took the time to re-read it, in light of what you propose, and it actually holds together remarkably well. In particular, I think your judgement on the casing / i18n issue is sound, and seeing it in the context of the whole document makes it feel like the most technologically neutral and acceptable solution. It puts no undue burdens on the traditions and best practices of the DNS community, nor on the email community. As you say, more work in a future Standards Track document can be done to extend the approach specified in the draft, but "doing so is also not required to determine the outcome of this experiment". One thing I wanted to bring to wider attention, though, was an observation I made in looking at RFC 4398 (which is referenced in section 1.1 of the draft). That RFC, Storing Certificates in the Domain Name System (DNS), says: > OpenPGP signed keys (certificates) use a general character string > User ID. However, it is recommended by OpenPGP that such names > include the RFC 2822 email address of the party, as in "Leslie > Example <Leslie@host.example>". If such a format is used, the CERT > ought to be under the standard translation of the email address into > a domain name, which would be leslie.host.example in this case. If > no RFC 2822 name can be extracted from the string name, no specific > domain name is recommended. (internal references removed). This is interesting because not only does it not consider a non-ASCII (or even give an example of a non-alphabetic) local-part, but it also happily lower-cases the local-part, "under the standard translation of the email address into a domain name". Admittedly this RFC is from 2006, and of course it is good that the IETF is now thinking harder about non-ASCII use cases, but I think that the fact that this RFC was accepted onto the Standards Track, with that approach to email addresses, reinforces your point that the experiment of dane-openpgp can safely go ahead while leaving some questions open until further data has been accumulated from wider deployment of this technology. I look forward to the closing of the extended LC, and to reading the IESG's review of the -08 draft. Best regards, Edwin