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-ietf-lemonade-profile-bis
Reviewer: Robert Sparks
Review Date: 10Feb09
IETF LC End Date: 19Feb09
IESG Telechat date: unknown
Summary: Mostly ready but with nits to address
1) This is a bis, but has no Updates/Obsoletes indicator - How is this
intended to affect RFC 4550? (The string "4550" appears nowhere in
this draft btw).
2) It's not clear whether the Forward without Download section is
intended to be "Here's a couple of ways you can realize this feature
if you have all the tools this profile requires available to you" or
"If you are going to realize this feature, please do it this way" or
"You MUST choose one of these ways if you are going to realize this
feature". It would help to make the abstract, introduction, and the
first part of section 8 more explicit. Similarly, the draft is
registering a keyword to use in a CAPABILITY response - it would help
if the abstract and section 5.7.1 made this very explicit.
3) The 2nd paragraph of section 5.2 motivates sing the BINARY
extension. The last sentence implies "size" - it should explicitly say
that. I'm also not certain the "always" in the sentence is actually
true?
4) Section 5.3 first paragraph has language that will not age well. Is
the appeal to current thinking necessary for this text? Saying
something more like "SHOULD support DEFLATE ... for TLS .. to
facilitate compression at as low a level as possible" would avoid it.
More importantly, if the intent is that these extensions get _used_ if
available, this section should be more explicit.
5) Section 7 paragraph 2: Is this document attempting to restate
RFC4409 requirements or make new ones that are different? If its just
pointing out consequences of following 4409, I strongly encourage you
to rewrite this paragraph without using 2119 words. For instance,
"When following the requirements stated in [SUBMIT] a client will
either connect to an explicitly configured port at the submission
server, or will default first to 587. [SUBMIT] allows subsequent
attempts at other ports, including 25, if the initial attempt fails.
See [SUBMIT] for information on why using port 25 is likely to fail ..."
6) (More a question that a comment) - Would the document benefit from
an explicit description of using $SubmitPending and $Submitted during
the description of putting the message only in the sent-folder and
using BURL when submitting it (at the end of section 8.6)?
7) Should you move the reference to 2821 forward?
Nits:
a) Section 4.1 paragraph 2 : Suggest either dropping the word "the" or
adding the word "extensions" to the end of the sentence.
b) Suggest changing the sense of 3rd paragraph of section 4.4 -
something like "MUST expand all BURL parts before evaluating the
supplied message size".
c) Section 5.4 first paragraph: "ransforms" should be "transforms"
d) Its not clear by the "This section is non-normative" sentence is
needed - I suspect an earlier review comment caused it to happen. If
you really need to keep it, I suggest finding a way to restate it such
that a non-native-english reader wouldn't have to work hard to know
you meant 5.11 and not 5 by "This section".
e) Its very hard to follow the transition from 8.3 to 8.4 - it would
be useful to have a "A new strategy" paragraph balancing the
"Traditional Strategy" section, followed by the "Step by step
description of the new strategy".
f) In section 8.4.1, the examples go A0051, A0052, then A0054... then
A0053 appears later in the same flow (but at a different server). If
I'm not confused, these values really have no relation with each other
(other than not-equal), so there's not an error, but you might be
misleading implementers into thinking there should be (cut-paste
implementation of examples happens).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
