Subject: [Gen-art] Genart LC review of draft-ietf-lemonade-profile-bis

From: Robert Sparks <[email-masked]>
Date: Tue, 10 Feb 2009 15:18:03 -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 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).

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 21 Feb 2009 22:44:53 +0000

> 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.

> 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  

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.

> 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 ..."
>

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.

> something like "MUST expand all BURL parts before evaluating the  

Changed, thanks.

> c) Section 5.4 first paragraph: "ransforms" should be "transforms"

Yes, fixed.

> 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  

Ok, I've changed that to "Section 5.11 is non-normative".

> 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.

> 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).

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Feb 2009 10:18:59 -0600

inline

On Feb 21, 2009, at 4:44 PM, Alexey Melnikov wrote:

<snip>

>> 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".
>

While a 3rd variant may be highly unlikely, unless you are really  
wanting to close the door on using one if it shows up, you should make  
a statement
about whether you intend these to be the methods to be exactly what  
people implement or that they are examples of how these tools might  
get used.

I think I'm hearing that the later is really what you mean (though  
you're saying "almost certainly will because their the natural choice"  
where I said "might").

It will save developers and architects a lot of time in the future to  
be explicit in the draft about that so they don't have to fight long  
semantic battles with product managers.
It will also inform interop arguments.

>
>
>> 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.
>

I don't understand your response - were you talking about the last  
comment I made above (about being more explicit that the draft is  
registering a new keyword?). If so, I don't think I made my point.
I'm looking for a sentence in the abstract that says something like  
"This document registers a new keyword for use in CAPABILITY  
responses". If you were responding to something else, please clarify.

<snip>
>> 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 ..."

In general, that's a very dangerous thing to do. Which document  
defines the normative behavior? If [SUBMIT] really is vague on the  
point, then there is an opportunity for different interpretations.
If you feel really strongly that 4409 needs to be clarified, consider  
an update to that document. If you want to leave the 2119 words in  
this document, but aren't intending to normatively update [SUBMIT],  
you should say exactly that.
(I think that's what you're trying to do with the "explicit usage of  
[SUBMIT] means that" qualifier, but I don't believe that's a clear  
enough indication to most readers.)

Thanks!

RjS

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Feb 2009 22:08:54 +0000

Hi Robert,

Robert Sparks wrote:

> wanting to close the door on using one if it shows up, you should 
> make  a statement
> about whether you intend these to be the methods to *be exactly what  
> get used*.
> you're saying "almost certainly will because their the natural 
> choice"  where I said "might").

Right.

> semantic battles with product managers.

While I can see the hypothetical situation you describe, most of the 
developers/architects are quite naive (to say politely), so they would 
be much better off not inventing something new, unless they know what 
they are doing. The document is trying to save them the troubles by 
showing 2 scenarios step-by-step.

But if you think that the document really need to state that example 
scenarios are informative, I can add that.

> It will also inform interop arguments.

I don't think there is an interop issue either way: a compliant server 
has to implement all pieces, so it would work correctly with both 
clients that implement scenario 1 or scenario 2.

> "This document registers a new keyword for use in CAPABILITY  responses".

Which is the same as saying that "This document defines a new IMAP 
extension ...".

Ok, I should have been clearer on this in my first reply. I thought this 
didn't belong to the Abstract, because it would have been an unnecessary 
clutter.
I also think that people who are going to look for what is included in 
the Lemonade Profile will find everything in sections 3.1, 3.2 and 3.3;
and people who are looking for this extension by name can find it in the 
IANA registry for IMAP extensions.

However, on a second thought, the Abstract already says:

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

So adding "The document also defines a new IMAP extension and registers 
some new IMAP keywords" after it doesn't look too bad.

(Just to confuse the matter: the keywords I am referring to in the last 
sentence are not the CAPABILITY keywords you were talking about earlier.)

> If you were responding to something else, please clarify.
>
> <snip>
>

Here is what RFC 4409 currently says:

3.1.  Submission Identification

   Port 587 is reserved for email message submission as specified in
   this document.  Messages received on this port are defined to be
   submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
   additional restrictions or allowances as specified here.

   Although most email clients and servers can be configured to use port
   587 instead of 25, there are cases where this is not possible or
   convenient.  A site MAY choose to use port 25 for message submission,
   by designating some hosts to be MSAs and others to be MTAs.

This text is targeted at operators/developers on mail submission servers. It is not helpful to client developers.
So the text is explaining the exact procedure to be used by clients.

Another reason for this text is to make sure that clients allow to connect to a port other than 25 for mail submission. Some existing clients still don't.

> an update to that document.

I would recommend that to authors of RFC 4409, sure. But I don't think 
this document should block on such revision.

> If you want to leave the 2119 words in  this document, but aren't 
> intending to normatively update [SUBMIT],  you should say exactly that.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Feb 2009 16:25:31 -0600

Hey Alexey - thanks for sticking with this:

<snip>

>> It will save developers and architects a lot of time in the future  
>> to  be explicit in the draft about that so they don't have to fight  
>> long  semantic battles with product managers.
>
> developers/architects are quite naive (to say politely), so they  
> would be much better off not inventing something new, unless they  
> know what they are doing. The document is trying to save them the  
> troubles by showing 2 scenarios step-by-step.
>

I think it would help, but my input is just one LC comment voice. Take  
that for what it is.

>
> So adding "The document also defines a new IMAP extension and  
> registers some new IMAP keywords" after it doesn't look too bad.
>
> (Just to confuse the matter: the keywords I am referring to in the  
> last sentence are not the CAPABILITY keywords you were talking about  
> earlier.)

I'm sure I introduced any confusion - sorry :)

>>>> 5) Section 7 paragraph 2: Is this document attempting to  
>>>> restate   RFC4409 requirements or make new ones that are different?
>>>
>>> language. Unfortunately RFC 4409 is a bit vague on this, so I  
>>> would  rather leave the text as is.
>>>
>>>> 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 ..."
>>>
> This text is targeted at operators/developers on mail submission  
> servers. It is not helpful to client developers.
> Another reason for this text is to make sure that clients allow to  
> connect to a port other than 25 for mail submission. Some existing  
> clients still don't.
>
>> If you feel really strongly that 4409 needs to be clarified,  
>> consider  an update to that document.
>
> I would recommend that to authors of RFC 4409, sure. But I don't  
> think this document should block on such revision.

I was in no way suggesting blocking the document because of this.
I still (again, just as a single LC commenter voice) think you'd be  
better off not using 2119 words here, and if you do use them,  
explicitly acknowledge that you are not
trying to update  4409.

>> (I think that's what you're trying to do with the "explicit usage  
>> of  [SUBMIT] means that" qualifier, but I don't believe that's a  
>> clear  enough indication to most readers.)
>>
>> Thanks!
>>
>> RjS
>
>