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

Glenn Parsons <glenn.parsons@ericsson.com> Tue, 10 January 2012 21:11 UTC

Return-Path: <glenn.parsons@ericsson.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA81421F85FC; Tue, 10 Jan 2012 13:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JZN9E96-ApbE; Tue, 10 Jan 2012 13:10:56 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9B45221F85F4; Tue, 10 Jan 2012 13:10:54 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0ALAbow017097; Tue, 10 Jan 2012 15:10:40 -0600
Received: from EUSAACMS0714.eamcs.ericsson.se ([]) by eusaamw0712.eamcs.ericsson.se ([]) with mapi; Tue, 10 Jan 2012 16:10:31 -0500
From: Glenn Parsons <glenn.parsons@ericsson.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-melnikov-smtp-priority.all@tools.ietf.org" <draft-melnikov-smtp-priority.all@tools.ietf.org>
Date: Tue, 10 Jan 2012 16:10:30 -0500
Thread-Topic: Review of draft-melnikov-smtp-priority-04
Thread-Index: AczP3Eif5ovw7p/HQ361wftFZGD5/A==
Message-ID: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_"
MIME-Version: 1.0
Cc: "iesg@ietf.org" <iesg@ietf.org>
Subject: [apps-discuss] Review of draft-melnikov-smtp-priority-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2012 21:11:03 -0000

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

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


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.


Standards Advisor

Ericsson Canada
3500 Carling Avenue
Ottawa, ON K2H 8E9, Canada
Phone +1 613 667 1569
Mobile +1 613 796 9407