"John" == John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
John> --On Monday, 25 September, 2006 11:07 -0700 Lisa Dusseault
John> <lisa(_at_)osafoundation(_dot_)org> wrote:
>> On Sep 23, 2006, at 2:20 AM, Julian Reschke wrote:
>>> But as a matter of fact, draft-newman-i18n-comparator-14
>>> doesn't define any collations that would actually solve the
>>> Unicode NF issue, so it's not really clear how this helps
>>> CalDAV (except that it now uses a framework in which the
>>> solution may become available in the future).
John> Please watch for the final version of
John> draft-iab-idn-nextsteps (probably to be posted as RFC 4690
John> within the next few days) and for
John> draft-???-idnabis-issues-00 (soon). Neither "solves" the NF
John> problem, but they may help make it more clear why the NF
John> problem is not solvable in any general case. It can be
John> solved for particular languages or, more specifically,
John> particular orthographies of particular languages. But, as
John> long as we are operating at the "Unicode" level, without
John> specific language-identifying information transmitted
John> in-band every time we transmit a string, there is no general
John> solution.
John> Fortunately, I don't b
I understand the IAB may be sold on this belief and it may even be
true. However, we do not ye.yet have an IETf consensus that this is
the case and we need to get there one way or another.
Since the publication of stringprep, the security community has (and
continues) to go full speed ahead on the assumption that we are
developing one stringprep profile for a protocol or group of related
protocol and that this will solve our comparison issues for most of
our protocol.
Changing that for security protocols is going to be significantly more
problematic than changes proposed for IDN.
So, people who have worked in relatively closed groups to come to
these conclusions for the specific domain of DNS really need to start
building a broader consensus--understanding the needs of the rest of
the IETF and working with the rest of the IETF to explain their
conclusions.
I don't say you are wrong--simply that you need to start the consensus
building and that I'm alarmed at your result.
In particular, in the security area, it would probably be strongly
desirable for us to have a discussion in San Diego.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf