Draft: draft-ietf-eai-framework-04 Reviewer: Robert Sparks [rjsparks@nostrum.com] Review Date: Friday 1/26/2007 1:30 PM IETF LC Date: 1/26/2007 IESG Telechat Date: 2/08/2007 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. 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.