Document: draft-ietf-lemonade-profile-bis-11
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).