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

Glenn Parsons <> Mon, 16 January 2012 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46D0921F85D5; Mon, 16 Jan 2012 15:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.809
X-Spam-Status: No, score=-4.809 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PRIOR=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FRS5ku3NJNLG; Mon, 16 Jan 2012 15:06:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 164CD21F85B5; Mon, 16 Jan 2012 15:06:56 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id q0GN6l7E023217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jan 2012 17:06:48 -0600
Received: from ([]) by ([]) with mapi; Mon, 16 Jan 2012 18:06:47 -0500
From: Glenn Parsons <>
To: Alexey Melnikov <>
Date: Mon, 16 Jan 2012 18:06:45 -0500
Thread-Topic: [apps-discuss] Review of draft-melnikov-smtp-priority-04
Thread-Index: AczUUNLU3XUN39iTQVuE5r8LTHt6XAAUPQhQ
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3FF5F8B6EUSAACMS0714e_"
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jan 2012 23:07:00 -0000


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

The use of the Priority SMTP service extension is valid for SMTP, the submission service  [RFC6409<>] and LMTP [RFC2033<>]3>].  The support of this SMTP extension is made separately and independently for each.

From: Alexey Melnikov []
Sent: January-15-12 1:35 PM
To: Glenn Parsons
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04

On 12/01/2012 17:42, Glenn Parsons wrote:

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

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.

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

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

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.
Ok, I will check.