Thanks to everyone who offered to help author, but that's not the issue - the current authors are interested, able, and involved.
Rather the issues include a lack of clear agreement on the email address processing and difficulty in getting actual review and feedback on drafts. We have quite active discussions on the ideas and concepts, but when it actually comes to review, comments and feedback on documents we often end up with silence. The email address processing solution that we have in openpgpkey is not perfect, but we think is good enough. We think that, after we have gotten some experience with how this works in openpgpkey we will be in a much better position to try solve the same issue in the SMIME document. I'll try chat more with my co-chair / the authors about betting an early allocation from IANA of a code-point. The advantage is that people can more easily test / experiment, the disadvantage (obviously) is that we may end up with differing implementations and interoperability issues in those experiments. Also, I;d like to apologize for us dropping the message on the list and then disappearing. Olafur and myself fell behind on mail because of the 4th of July / Independence Day ( https://en.wikipedia.org/wiki/Independence_Day_(United_States) for non-US folk) vacation / travel / etc. W On Thu, Jul 2, 2015 at 12:40 PM, Peter Saint-Andre - &yet <[email protected]> wrote: > On 7/2/15 10:33 AM, Wil Tan wrote: >> >> >> On Fri, Jul 3, 2015 at 1:47 AM, Peter Saint-Andre - &yet >> <[email protected] <mailto:[email protected]>> wrote: >> >> On 7/2/15 8:34 AM, Paul Wouters wrote: >> >> On Thu, 2 Jul 2015, Viktor Dukhovni wrote: >> >> So for me, the main obstacle is still the owner-label, which >> is >> the same for both OPENPGP and SMIMEA. >> >> >> No one has given me feedback (positive or negative) on the >> "lowercase if >> ascii, normalise otherwise", then lookup base32/split or using >> hash, >> that was advised to me by some of the EAI people. >> >> >> What exactly do we mean by "normalise" here? I don't see anything >> about normalization (in the Unicode sense) in >> draft-ietf-dane-openpgpkey. >> >> >> It's not in the draft; we were discussing this in Buenos Aires with Paul. >> >> I believe it was suggested that we use Unicode default case folding >> (Section 3.13 - >> http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992). >> >> I'm not convinced that we should touch non-ASCII mailbox username. > > > I tend to agree. > >> As for ASCII - the only well-known case for locale-sensitive mapping is >> the Turkish dotted/dotless i. > > > In my experience it's usually not safe to say "the only case" when it comes > to internationalization. ;-) > >> If we lowercased capital I according to >> Turkish locale, we'd get U+0131 (small letter dotless i) which is not >> ASCII; see above. So my preference is to "lowercase if ascii, otherwise >> verbatim". > > > Well, locale-specific case mapping is not part of Unicode Default Case > Folding, so applying the latter should be fine. > > See also https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ on > some of these topics. > > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
