Subject: [Gen-art] gen-art LC review: draft-ietf-eai-framework-04

From: Robert Sparks <[email-masked]>
Date: Fri, 26 Jan 2007 13:29:35 -0600

I am the assigned Gen-ART reviewer for draft-ietf-eai-framework-04
For background on Gen-ART, please see the FAQ at <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.

Summary: This draft is basically ready for publication, but has nits  
that should be fixed before publication.

John -

I see no significant issues to raise with this draft, but I do have  
some questions and some minor suggestions.

1: This is the envelope draft for a suite of experimental drafts if I  
read the charter page correctly. I suspect this draft made that  
extremely clear in an earlier version, but it's muddy in this one.  
Reinforcing that in the abstract, intro, or overview would help new  
readers better understand the game-plan and make the document make  
more sense when someone pulls it up 5 years from now.

2: How close are some of the mechanics drafts to publication? Will  
they be right on the heels of this? If not, what's the advantage  
being sought for publishing this now? What's the risk that the  
document plan will need to change?  (This question is motivated by  
the uncertainty in, for example, the second bullet of the document  
plan and the running train leading to things like the comment in the  
reference for [EAI-DSN]).

3: The general principles on page 8 capture design decisions  
(particularly 3) that affect the overall approach the document suite  
is taking. Would it be helpful to say "Some general principles  
affecting the design decisions to be made in this work" to reinforce  
their importance?

4. First sentence, last paragraph of 4.2: I can't parse this sentence  
and am not sure enough of what it's trying to say to suggest an  
alternative.

5. The SHOULD in the last paragraph of 5.2 surprised me. Would it  
make sense to document in the draft why the WG decided to not make  
this MUST?

Editorial nits/suggestions:

a. Last sentence of 1.2: Should "headers not have content-transfer- 
encodings" say "headers do not have content-transfer-encodings"?

b. I see some potential confusion in the definition of "ASCII user"  
in the terminology section centered around "exclusively uses". (And  
trying to suggest text shows that it's hard to make this better). The  
intent here is to say that the user only receives mail through  
addresses that contain only ASCII characters. "Uses" could be read to  
encompass addresses sent to. That's covered by part ii), but I could  
still see someone getting lost. Is there a phrase like "receives mail  
through addresses that contain only ASCII" that clarifies that  
without stepping on some other trap?

c. Would it be reasonable to put document references in the bullets  
at the start of 4.1, and explicitly point to 4.2 instead of saying  
"the next subsection"?

d. Last sentence on page 8: "and similarly for POP" might lose a non- 
native-English reader.

e. In 4.3, you basically say "There are two cases and here are all  
three of them". It might be less confusing to someone having to  
translate to avoid that structure. Perhaps saying "For situations in  
which a client that needs to use UTF8SMTP encounters a server that  
does not support the extension, there are two possibilities", and  
change "There is also a third case" paragraph to start "If a UTF8SMTP  
capable client is sending a message that does not require the  
extended capabilities, it SHOULD send the message whether or not the  
server announces support for the extension."

f. The first sentence of section 5.1 is quite complex. Would breaking  
it into more sentences help?

g. I suggest substituting the last two sentences in the first  
paragraph of section 9 with "It should be noted that the proposed fix  
involving forcing all displayed elements into normalized lower-case  
works for domain names in URLs, but not email local parts since those  
are case sensitive". I had to scan back several times over the  
original sentences.

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