Robert Sparks wrote:
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
Hi Robert,
Thank you for your review.
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).
Good point. The document obsoletes RFC 4550. I've updated my copy to say
that.
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".
I don't think the difference between 3 variants really matters. A
combination of Submission and IMAP servers allows the client to use
either approach.
If a client writer can invent a third approach based on advertised
extensions, I would be impressed ;-).
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.
Actually section 3.2 lists the URL-PARTIAL capability in the table of
required extensions, so I think this should be clear already.
3) The 2nd paragraph of section 5.2 motivates using the BINARY
extension. The last sentence implies "size" - it should explicitly
say that.
Fixed.
I'm also not certain the "always" in the sentence is actually true?
This statement is true for all Content-Transfer-Encodings registered in
<http://www.iana.org/assignments/transfer-encodings/transfer-encodings.xhtml>
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.
Ok, I've changed the sentence as you suggested.
More importantly, if the intent is that these extensions get _used_
if available, this section should be more explicit.
Section 3.2 does that already, so I don't think this is necessary.
5) Section 7 paragraph 2: Is this document attempting to restate
RFC4409 requirements or make new ones that are different?
It is trying to restate RFC 4409 requirements, but using stronger
language. Unfortunately RFC 4409 is a bit vague on this, so I would
rather leave the text as is.
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)?
Good point. I think a reference to the section describing $SubmitPending
and $Submitted should be added to section 8.6.
7) Should you move the reference to 2821 forward?
Yes, this is already fixed in my copy.
Nits:
a) Section 4.1 paragraph 2 : Suggest either dropping the word "the"
or adding the word "extensions" to the end of the sentence.
Good point. Thanks.
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".
Changed, thanks.
c) Section 5.4 first paragraph: "ransforms" should be "transforms"
Yes, fixed.
d) Its not clear by the "This section is non-normative" sentence is
needed
Yes, as the WG has debated whether extensions listed in this section are
mandatory to implement.
- 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".
Ok, I've changed that to "Section 5.11 is non-normative".
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".
I've renamed section 8.4 to say "A new strategy". And section 8.4
already says that its subsections contain step-by-step instructions, so
I don't think new sections are needed.
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).
Actually A0053 is at the same server. But it is more logical if A0053
follows A0052, so I've changed the tags.
If I'm not confused, these values really have no relation with each other
Correct.
(other than not-equal
In practice even that is not required. But reusing the same tag for
multiple commands is going to be very confusing.
), 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
