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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
