New version, draft-faltstrom-idnabis-tables-02.txt, available
simon at josefsson.org
Thu Jun 14 10:28:58 CEST 2007
Kenneth Whistler <kenw at sybase.com> writes:
>> As a different question than whether
>> you feel it is hard to follow or "not the most optimal way of
>> describing what we want to do".
>>From RFC 2026:
> "The goals of the Internet Standards Process are:
> o technical excellence;
> o prior implementation and testing;
> o clear, concise, and easily understood documentation;
> o openness and fairness; and
> o timeliness."
> It seems to me that this entire process to update IDNA is
> in danger of failing on all 5 of those criteria.
I share those concerns. It seems that a better way to handle this would
be to bring this up as a BOF/WG and set up a proper IETF mailing list
for these discussion, and invite participators from other areas that use
these specification -- I'm thinking of the SASLPrep crowd.
I suggest that every change to the IDNA protocols is clearly discussed
and motivated in a requirements document that is developed in parallel
with the IDNAbis document.
If there is such a document, people will be able to understand WHY a
certain thing has changed in IDNA, and the process will be much more
transparent. Reviewing the IDNAbis work today is very difficult since
there is no justification for each change. It should be made easy to
trace back any particular change to a description of why something isn't
working properly today.
Personally, I haven't invested time to follow the current IDNAbis effort
since it doesn't appear evident to me that its output will be accepted
by the wider community.
More information about the Idna-update