--On Tuesday, 06 November, 2007 21:18 -0600 Spencer Dawkins
<spencer(_at_)mcsr-labs(_dot_)org> wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call
comments
you may receive.
Document: draft-klensin-unicode-escapes-06.txt
Reviewer: Spencer Dawkins
Review Date: 2007-11-08
IETF LC End Date: 2007-11-15
IESG Telechat date:
Summary: This document is ready for publication as a BCP, with
one question and one comment for the sponsoring AD. I should
also mention that the document is very clear and well-written.
Comments: This document uses a fair amount of SHOULD/SHOULD
NOT language without a lot of explanation about why the
SHOULDs are not MUSTs. I'm not sure what's appropriate for an
APPS-area BCP, but I usually ask about SHOULD/SHOULD NOT
without guidance.
This is a BCP that recommends two different encoding escapes.
If the SHOULDs are something like "MUST unless you're using
the other method", is 2119 language even needed?
That is a good question. Some small part of that language is
the result of the evolution of this document from one strong
recommendation, to no recommendation at all, to a pair of
alternative recommendations, neither of which was the original
one. (So much for the theory that individual submissions don't
change during IETF discussion.) I'd be happy to change it to
"you MUST use one or the other" if that is what the community
prefers, but there actually are reasons for the weaker language:
there are probably protocols that are closely tied to a
particular programming language or existing protocol that would
be better off following their practices than these
recommendations.
One example that came up in the discussions involved IRIs. URIs
use escaped (hexified) UTF-8, which, as you probably inferred
from the document, is one of my least favorite choices. IRIs
stayed with that convention to keep things from becoming even
worse as the two types of escapes got confused. I personally
think that may have been the wrong choice, but my belief is part
of a more general impression that IRIs didn't go nearly far
enough in the direction of internationalization to be really
useful. And, since we seem to be trapped in that direction, I
suspect there can be a strong case made that some future
protocol that builds in IRIs and URIs should follow the same
path... hence SHOULD.
I didn't discuss those exception cases in the draft for two
reasons. First, no one before this has asked for that
discussion. Second, I find most of the cases I've been able to
think of, including the one above, to be distasteful and didn't
want to explain them in a way that would give those who like
them better than I do an excuse and rationale.
best,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf