Subject: [apps-discuss] Review of draft-melnikov-smtp-priority-04

From: Glenn Parsons <[email-masked]>
Date: Tue, 10 Jan 2012 16:10:30 -0500

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
Document: draft-melnikov-smtp-priority-04
Title: Simple Mail Transfer Protocol extension for Message Priorities
Reviewer: Glenn Parsons
Review Date:  January 10, 2012

Summary:
This draft is not ready for publication as a Proposed Standard and should be revised before publication
Major Issues:
3.  in item #7 I presume this should be LMTP, but my concern is that it says this is being defined for LMTP.  Since LMTP is informational, I don't think that is appropriate.  Instead, I would suggest that it is defined for Message Submission and as a result may also be used for LMTP.   I would prefer this to be noted in an Appendix (along with the LMTP advice in section 7) -- but if you would prefer it to remain in the main body, it needs to be reworded.  In either case, I would move LMTP to the informative references.
3.  the too long example in 3.1 is apparently justified by item #6 here ... but you can't have a line longer than 72 chars in an RFC... but more importantly, how do you guarantee that this does not accidentally blow something up.  This is a HUGE change that is mentioned in passing without justification.  This seems like a large hurdle for an implementation to be able to add support for this.  The use for this appears to be to fit in message size parameters for each priority (and I presume the message size is in bytes as it does not say).  So why not use Kb instead of bytes?  Or render the numbers in hex?  Or split it over two lines?  I think any of these would be better than increasing the line length.
5. The priority level definition is not clear.  There are 200 possible values.  But there MUST be at least 6 supported.  OK that seems like overkill -- why can't it be from -9 to 9 then?  Anyway, is that 6 distinct numbers, 6 distinct numbers from the range shown, or any number for the range shown?  Further I would  suggest that a default value should be specified for these 6 levels and the default mapping ranges -- all in a table.
6 & 8. You need to pick something and be consistent.  I would suggest it is not necessary for them to be the same.  So the EHLO one could be short "PRI" and the header long "Message Transfer Priority".  In any case, the terminology then needs alignment throughout the document.
A definition of the Priority message header field is missing.  It should be after section 3.

Minor Issues:
Title:  I would change "Message Priorities " to "Message Transfer Priority"
6. The units for "message size" need to be indicated at some point in the document, at least in the syntax of section 6.
3. I would suggest to replace "The following service extension is defined:" with "The Priorty SMTP service extension is defined as follows:"
5.1.x I am somewhat concerned about informative implementation details -- I presume that is why this is informative?  Or is it because this is not exhaustive?  In any case, I think this should be in the appendix.
6. It is confusing to have both specifications for the ESMTP and Header field in the same place.   I would suggest separate appropriatley titled sub-sections of section 6
7.  I would suggest adding an example fo the message header field in this clause.
9.  What are the "anchor" placeholders for?
9. Presumably the TBD items need to be filled in...

Nits:

3.1 the example is too long

** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72.
...but I could not find this one:
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document.

 <http://www.ericsson.com/current_campaign>

GLENN PARSONS
Standards Advisor

Ericsson Canada
3500 Carling Avenue
Ottawa, ON K2H 8E9, Canada
Phone +1 613 667 1569
Mobile +1 613 796 9407
[email-masked]
www.ericsson.com

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Jan 2012 12:48:32 +0000

Hi Glenn,
Thank you for your review.

On 10/01/2012 21:10, Glenn Parsons wrote:
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 
>
> Please resolve these comments along with any other Last Call comments 
> you may receive. Please wait for direction from your document shepherd 
> or AD before posting a new version of the draft.
> 3.  in item #7 I presume this should be LMTP, but my concern is that 
> it says this is being defined for LMTP.  Since LMTP is informational, 
> I don't think that is appropriate.  Instead, I would suggest that it 
> is defined for Message Submission and as a result may also be used for 
> LMTP.   I would prefer this to be noted in an Appendix (along with the 
> LMTP advice in section 7) -- but if you would prefer it to remain in 
> the main body, it needs to be reworded.  In either case, I would move 
> LMTP to the informative references.
I know that LMTP (RFC 2033) being Informational is annoying, but really, 
it is a perfectly valid DownRef and can be called out during IETF LC.
(At some point LMTP should be promoted to Proposed Standard, but that is 
largely independent of this work.)
> 3.  the too long example in 3.1 is apparently justified by item #6 
> here ... but you can't have a line longer than 72 chars in an RFC...
I think I've fixed that in my copy.
> but more importantly, how do you guarantee that this does not 
> accidentally blow something up.  This is a HUGE change that is 
> mentioned in passing without justification.  This seems like a large 
> hurdle for an implementation to be able to add support for this.
Why? Advertisement of supported levels is entirely optional.
> The use for this appears to be to fit in message size parameters for 
> each priority (and I presume the message size is in bytes as it does 
> not say).
Yes, in bytes. Clarified in my copy.
> So why not use Kb instead of bytes?
I was trying to be consistent with the SIZE SMTP extension which also 
uses bytes. But as you are the second person to complain about that, 
maybe I will give up and switch to Kb ;-).
> Or render the numbers in hex?  Or split it over two lines?
The last doesn't work well with SMTP. At least no SMTP extension ever 
listed more than 1 capability in EHLO response.
> I think any of these would be better than increasing the line length.
> 5. The priority level definition is not clear.  There are 200 possible 
> values.  But there MUST be at least 6 supported.  OK that seems like 
> overkill -- why can't it be from -9 to 9 then?  Anyway, is that 6 
> distinct numbers, 6 distinct numbers from the range shown, or any 
> number for the range shown?  Further I would  suggest that a default 
> value should be specified for these 6 levels and the default mapping 
> ranges -- all in a table.
As other people made the same comment, I will reply to this with my 
reasoning in a separate email.
> 6 & 8. You need to pick something and be consistent.  I would suggest 
> it is not necessary for them to be the same.  So the EHLO one could be 
> short "PRI" and the header long "Message Transfer Priority".  In any 
> case, the terminology then needs alignment throughout the document.
I think a forward reference in section 4.2 (where the MT-Priority header 
field is specified) would be sufficient. Unless you meant something else.
> 6. The units for "message size" need to be indicated at some point in 
> the document, at least in the syntax of section 6.
This is already fixed in my copy (will be in -05).
> 3. I would suggest to replace "The following service extension is 
> defined:" with "The Priorty SMTP service extension is defined as 
> follows:"
> 5.1.x I am somewhat concerned about informative implementation details 
> -- I presume that is why this is informative?  Or is it because this 
> is not exhaustive?
Mostly the latter.
> In any case, I think this should be in the appendix.
Ok.
> 6. It is confusing to have both specifications for the ESMTP and 
> Header field in the same place.   I would suggest separate 
> appropriatley titled sub-sections of section 6
This is just a hint to RFC Editor to insert the final RFC number, once 
known.
> 9. Presumably the TBD items need to be filled in...
The 2 values will be assigned by IANA before publication.
> == There are 1 instance of lines with non-RFC2606-compliant FQDNs in 
Ok, I will check.

---

From: Glenn Parsons <[email-masked]>
Date: Thu, 12 Jan 2012 12:42:44 -0500

Alexey,

You're welcome :-)

Despite your assertion that LMTP would be a valid DownRef ... I do not think this extension should be defined for it.  That is I would suggest adding text along the lines of ...it is defined for Message Submission and as a result may also be used for LMTP.

On lines longer than 72 -- it just feels bad.  And further, you have no justification for this here.  Is it for the message length?  If it is won't moving to Kb remove the need for a longer line?

On the naming you need to be consistent.  For example, is it "PRI" or "PRIORITY"

On docuemnt organization, there are two things defined here:  Priority SMTP extension & Priority message header.  These need to be in distinct sections with appropriate titles.  It is the second that is currently hidden.

Cheers,
Glenn.

________________________________
From: Alexey Melnikov [mailto:[email-masked]]
Sent: January-11-12 7:49 AM
To: Glenn Parsons
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04

Hi Glenn,

On 10/01/2012 21:10, Glenn Parsons wrote:
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
Document: draft-melnikov-smtp-priority-04
Title: Simple Mail Transfer Protocol extension for Message Priorities
Reviewer: Glenn Parsons
Review Date:  January 10, 2012
Summary:
This draft is not ready for publication as a Proposed Standard and should be revised before publication
Major Issues:
3.  in item #7 I presume this should be LMTP, but my concern is that it says this is being defined for LMTP.  Since LMTP is informational, I don't think that is appropriate.  Instead, I would suggest that it is defined for Message Submission and as a result may also be used for LMTP.   I would prefer this to be noted in an Appendix (along with the LMTP advice in section 7) -- but if you would prefer it to remain in the main body, it needs to be reworded.  In either case, I would move LMTP to the informative references.
I know that LMTP (RFC 2033) being Informational is annoying, but really, it is a perfectly valid DownRef and can be called out during IETF LC.
(At some point LMTP should be promoted to Proposed Standard, but that is largely independent of this work.)
3.  the too long example in 3.1 is apparently justified by item #6 here ... but you can't have a line longer than 72 chars in an RFC...
I think I've fixed that in my copy.
but more importantly, how do you guarantee that this does not accidentally blow something up.  This is a HUGE change that is mentioned in passing without justification.  This seems like a large hurdle for an implementation to be able to add support for this.
Why? Advertisement of supported levels is entirely optional.
The use for this appears to be to fit in message size parameters for each priority (and I presume the message size is in bytes as it does not say).
Yes, in bytes. Clarified in my copy.
So why not use Kb instead of bytes?
I was trying to be consistent with the SIZE SMTP extension which also uses bytes. But as you are the second person to complain about that, maybe I will give up and switch to Kb ;-).
Or render the numbers in hex?  Or split it over two lines?
The last doesn't work well with SMTP. At least no SMTP extension ever listed more than 1 capability in EHLO response.
I think any of these would be better than increasing the line length.
5. The priority level definition is not clear.  There are 200 possible values.  But there MUST be at least 6 supported.  OK that seems like overkill -- why can't it be from -9 to 9 then?  Anyway, is that 6 distinct numbers, 6 distinct numbers from the range shown, or any number for the range shown?  Further I would  suggest that a default value should be specified for these 6 levels and the default mapping ranges -- all in a table.
As other people made the same comment, I will reply to this with my reasoning in a separate email.
6 & 8. You need to pick something and be consistent.  I would suggest it is not necessary for them to be the same.  So the EHLO one could be short "PRI" and the header long "Message Transfer Priority".  In any case, the terminology then needs alignment throughout the document.
A definition of the Priority message header field is missing.  It should be after section 3.
I think a forward reference in section 4.2 (where the MT-Priority header field is specified) would be sufficient. Unless you meant something else.
Minor Issues:
Title:  I would change "Message Priorities " to "Message Transfer Priority"
6. The units for "message size" need to be indicated at some point in the document, at least in the syntax of section 6.
This is already fixed in my copy (will be in -05).
3. I would suggest to replace "The following service extension is defined:" with "The Priorty SMTP service extension is defined as follows:"
5.1.x I am somewhat concerned about informative implementation details -- I presume that is why this is informative?  Or is it because this is not exhaustive?
Mostly the latter.
In any case, I think this should be in the appendix.
Ok.
6. It is confusing to have both specifications for the ESMTP and Header field in the same place.   I would suggest separate appropriatley titled sub-sections of section 6
7.  I would suggest adding an example fo the message header field in this clause.
9.  What are the "anchor" placeholders for?
This is just a hint to RFC Editor to insert the final RFC number, once known.
9. Presumably the TBD items need to be filled in...
The 2 values will be assigned by IANA before publication.
Nits:

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Jan 2012 18:35:20 +0000

On 12/01/2012 17:42, Glenn Parsons wrote:
> Alexey,
> You're welcome :-)
> Despite your assertion that LMTP would be a valid DownRef ... I do not 
> think this extension should be defined for it.
If your suggestion is based on procedural ground, then I don't think it 
is valid (please point out to a document which says that Informative 
reference can't be used normatively). If you suggest this for some other 
reason, can you please elaborate?
> That is I would suggest adding text along the lines of ...it is 
> defined for Message Submission and as a result may also be used for LMTP.
I don't think that would be correct. There are 3 essentially different 
protocols: Mail Submission, SMTP used to talk to MTAs, and LMTP. For 
each one the decision about whether an SMTP extension can be used with 
it needs to be made separately and independently.
> On lines longer than 72 -- it just feels bad.
SMTP line length limits are generally much higher, but I see your point.
> And further, you have no justification for this here.  Is it for the 
> message length?
Yes.
> If it is won't moving to Kb remove the need for a longer line?
Ok, will do :-).
> On docuemnt organization, there are two things defined here:  Priority 
> SMTP extension & Priority message header.  These need to be in 
> distinct sections with appropriate titles.  It is the second that is 
> currently hidden.
Ok.
> Cheers,
> Glenn.
> ------------------------------------------------------------------------
> *From:* Alexey Melnikov [mailto:[email-masked]]
> *Sent:* January-11-12 7:49 AM
> *To:* Glenn Parsons
> *Cc:* [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04
>
> Hi Glenn,
>> I have been selected as the Applications Area Directorate reviewer 
>> for this draft (for background on appsdir, please see 
>> you may receive. Please wait for direction from your document 
>> shepherd or AD before posting a new version of the draft.
>> is defined for Message Submission and as a result may also be used 
>> for LMTP.   I would prefer this to be noted in an Appendix (along 
>> with the LMTP advice in section 7) -- but if you would prefer it to 
>> remain in the main body, it needs to be reworded.  In either case, I 
>> would move LMTP to the informative references.
> I know that LMTP (RFC 2033) being Informational is annoying, but 
> really, it is a perfectly valid DownRef and can be called out during 
> IETF LC.
>> 5. The priority level definition is not clear.  There are 200 
>> possible values.  But there MUST be at least 6 supported.  OK that 
>> seems like overkill -- why can't it be from -9 to 9 then?  Anyway, is 
>> that 6 distinct numbers, 6 distinct numbers from the range shown, or 
>> any number for the range shown?  Further I would  suggest that a 
>> default value should be specified for these 6 levels and the default 
>> mapping ranges -- all in a table.
>> it is not necessary for them to be the same.  So the EHLO one could 
>> be short "PRI" and the header long "Message Transfer Priority".  In 
>> any case, the terminology then needs alignment throughout the document.
> I think a forward reference in section 4.2 (where the MT-Priority 
> header field is specified) would be sufficient. Unless you meant 
> something else.
>> Minor Issues:
>> 5.1.x I am somewhat concerned about informative implementation 
>> details -- I presume that is why this is informative?  Or is it 
>> because this is not exhaustive?
> Mostly the latter.

---

From: Glenn Parsons <[email-masked]>
Date: Mon, 16 Jan 2012 18:06:45 -0500

Alexey,

My objection on LMTP is not procedural, I just think it is cleaner to define the SMTP Extension normatively as-is.  This extension does not need LMTP as a normative reference to be valid for LMTP -- but my real concern is that it should not be "defined" for LMTP.

So I suggest changing section 3 to not have LMTP in the defined enumerated list:

The Priorty SMTP service extension is defined as follows:
1. ...
2.
3.
4.
5.
6. ...

The use of the Priority SMTP service extension is valid for SMTP, the submission service  [RFC6409<http://tools.ietf.org/html/rfc6409>] and LMTP [RFC2033<http://tools.ietf.org/html/rfc2033>].  The support of this SMTP extension is made separately and independently for each.
Cheers,
Glenn.

Sent: January-15-12 1:35 PM

You're welcome :-)

Despite your assertion that LMTP would be a valid DownRef ... I do not think this extension should be defined for it.
If your suggestion is based on procedural ground, then I don't think it is valid (please point out to a document which says that Informative reference can't be used normatively). If you suggest this for some other reason, can you please elaborate?
That is I would suggest adding text along the lines of ...it is defined for Message Submission and as a result may also be used for LMTP.
I don't think that would be correct. There are 3 essentially different protocols: Mail Submission, SMTP used to talk to MTAs, and LMTP. For each one the decision about whether an SMTP extension can be used with it needs to be made separately and independently.
On lines longer than 72 -- it just feels bad.
SMTP line length limits are generally much higher, but I see your point.
And further, you have no justification for this here.  Is it for the message length?
Yes.
If it is won't moving to Kb remove the need for a longer line?
Ok, will do :-).
On the naming you need to be consistent.  For example, is it "PRI" or "PRIORITY"

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Glenn,

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Jan 2012 12:45:33 +0000

Hi Glenn,
To answer your question about the number of priority levels:

On 10/01/2012 21:10, Glenn Parsons wrote:
> _http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate_). 
>
[...]
> values.
The document originally had 5 fixed levels. I received comments from 
some people that they would like to use this extension, but for their 
environment they wanted to use N levels (N > 5), or maybe M levels, but 
they were not quite the same as the one recommended in the draft. One 
proposal asked for having a language for expressing policy associated 
with each priority level and use names instead of numbers. I felt that 
use of names for priority levels was overkill, so instead I've expanded 
the range of allowed numeric priorities. The main nice property of this 
is that the range of allowed priorities allows an implementation to 
insert additional priority levels in gaps between recommended priorities 
(e.g. if -8, -6,-2,0,+2,+6,+10 are defined, one can define a new 
priority level of +7 if really needed).
> But there MUST be at least 6 supported.  OK that seems like overkill 
> -- why can't it be from -9 to 9 then?
I think this will work. I was certainly not thinking that all 200 
distinct priority levels should be implemented.
> Anyway, is that 6 distinct numbers, 6 distinct numbers from the range 
> shown, or any number for the range shown?
Any number from the range shown, but at least 6 of them.
> Further I would  suggest that a default value should be specified for 
> these 6 levels and the default mapping ranges -- all in a table.
**Ok.

So it looks like I need to (a) reduce the number of allowed priorities, 
(b) clarified how they are to be used and why there are more than 6 and 
(c) recommend a default mapping.