Subject: [Gen-art] Genart review of draft-ietf-lemonade-profile-bis-07 (followup to -06)

From: Robert Sparks <[email-masked]>
Date: Fri, 6 Mar 2009 14:01:06 -0600

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-lemonade-profile-bis-07
Reviewer: Robert Sparks
Review Date: 6 March 2009
IESG Telechat date: 12 March 2009

Summary: Ready for publication as Proposed Standard

All the comments below have been responded to.

The editor disagrees that any change is needed to address comments 2  
and 5 below.

I do not object to publishing this document without these changes, but  
still feel it would be an improvement. Please consider point 5 in  
particular.

RjS

On Feb 10, 2009, at 3:18 PM, 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
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Mar 2009 00:11:12 +0000

Robert Sparks wrote:

> I do not object to publishing this document without these changes, 
> but  still feel it would be an improvement. Please consider point 5 
> in  particular.

Robert,
Let me suggest some RFC editor notes based on our earlier discussions. 
But note that they might not address all of your remaining issues:

1). Change the second paragraph of the Abstract from:
OLD:

   The Lemonade profile relies upon several extensions to IMAP and Mail
   Submission protocols.

NEW:

   The Lemonade profile relies upon several extensions to IMAP, Sieve and Mail
   Submission protocols. The document also defines a new IMAP extension and
   registers several new IMAP keywords.

In section 7, please change the 2nd paragraph:

OLD:
   Note that the explicit usage of [SUBMIT] means that when opening a
   connection to the submission server, clients MUST do so using port
   587 unless explicitly configured to use an alternate port [RFC5068].
   If the TCP connection to the submission server fails to open using
   port 587, the client MAY then immediately retry using a different
   port, such as 25.  See [SUBMIT] information on why using port 25 is
   likely to fail depending on the current location of the client, and
   may result in a failure code during the SMTP transaction.

NEW:
   When opening a connection to the submission server, clients MUST do
   so using port 587 unless explicitly configured to use an alternate
   port [RFC5068]. (Note that this requirement is somewhat stronger than
   the one specified in [SUBMIT], as [SUBMIT] didn't prescribe exact
   procedure to be used by submission clients.)
   If the TCP connection to the submission server
   fails to open using port 587, the client MAY then immediately retry
   using a different port, such as 25.
   See [SUBMIT] information on why using port 25 is
   likely to fail depending on the current location of the client, and
   may result in a failure code during the SMTP transaction.

In Section 8.4, change the 1st sentence of the 3rd paragraph to read:

OLD:
   There are two ways to perform "forward without download" based on
   where the message assembly takes place.

NEW:
   This section informatively describes two ways to perform "forward
   without download" based on where the message assembly takes place.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 Mar 2009 22:25:40 -0500

Thanks Alexey!

I think those changes will help.

RjS

On Mar 9, 2009, at 7:11 PM, Alexey Melnikov wrote:

>> The editor disagrees that any change is needed to address comments  
>> 2  and 5 below.
>>
> Let me suggest some RFC editor notes based on our earlier  
> discussions. But note that they might not address all of your  
> remaining issues:
>
>>> this intended to affect RFC 4550? (The string "4550" appears  
>>> nowhere  in this draft btw).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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 ..."
>>>
>>> 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)?
>>>
>>> a) Section 4.1 paragraph 2 : Suggest either dropping the word  
>>> "the"  or adding the word "extensions" to the end of the sentence.
>>>
>>> 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".
>>>
>>> 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).