Subject: Gen-ART Last Call review of draft-klensin-unicode-escapes-06.txt

From: Spencer Dawkins <[email-masked]>
Date: Tue, 06 Nov 2007 21:18:18 -0600

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?

Thanks,

Spencer 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Nov 2007 22:52:04 -0500

--On Tuesday, 06 November, 2007 21:18 -0600 Spencer Dawkins
<[email-masked]> wrote:

> 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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2007 12:54:42 -0500

I definitely think it is important that when using a URI or IRI in
another protocol to be able to follow the conventions of the URI or
IRI.  Similarly, even if we find a convention that we don't like I
think it is valuable to be able to build on existing work rather than
introduce confusion.

--Sam

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 08 Nov 2007 17:23:01 -0600

So ... it seems to me that based on Sam's note, and John's previous note, a 
short statement at the beginning of the document that says approximately 
what Sam said would be very helpful. I'm not looking to challenge every 
SHOULD, especially in a BCP.

It would be helpful to say "this is our best guidance. There may be 
considerations that lead you to use other approaches (for example, building 
on existing work that uses other escapes), but consider the shortcomings of 
those approaches in making this decision".

Or something like that.

Thanks,

Spencer