IETF Logo Mail Archive

[apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-13

S Moonesamy <sm+ietf@elandsys.com> Mon, 21 May 2012 22:19 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BE221F84A7; Mon, 21 May 2012 15:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level:
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPgmObaelgHq; Mon, 21 May 2012 15:19:57 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B92921F84A6; Mon, 21 May 2012 15:19:57 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.238.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4LMJewB029014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 15:19:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1337638795; i=@elandsys.com; bh=4sQda7Ssi5AVr9KtjDnDr+tLDZeQl6O9la2+KnODIUY=; h=Date:To:From:Subject:Cc; b=igLt1W16Mdg3ge5NbTGHqzrTgbtxNwoPdzaizGlalBOUROlZx3Qyr6SYI1haGgWy8 XSXsctz9kXGLbS2QjeGZF9NwMClDyRA2PTmWYK9XebYd0polvCqQNzyiALBjWCuyfX khkvyv8iU75zWcH9+GZhVzbdC4IlHfp1mKNbhh4Y=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1337638795; i=@elandsys.com; bh=4sQda7Ssi5AVr9KtjDnDr+tLDZeQl6O9la2+KnODIUY=; h=Date:To:From:Subject:Cc; b=HH9dvLzV3z6QywdrpM34BQZxOJbO16uneJoFo9qHjbRKZk8KmAn5XJ/2wgIA0Ldn0 nItj1D2Hs6CETELdOGHBJY0u25a0E0/2p5MIEzBC9qCQp/bEcEIfb5cXp1s7HLqmd9 4H8IGe1Uf67Qt/SdzVaApZVP7nJzHGmfDDsNso4g=
Message-Id: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 21 May 2012 15:05:25 -0700
To: apps-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: draft-melnikov-smtp-priority-13.all@tools.ietf.org, iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-13
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: Mon, 21 May 2012 22:19:58 -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 ).

The comments in this review do not bear more weight than comments 
submitted by an individual during a Last Call.  It is suggested that 
the author ask the document shepherd for guidance about any changes 
suggested in a review.

Please note that this is a follow-up to a previous review.

Document: draft-melnikov-smtp-priority-13
Title: Simple Mail Transfer Protocol extension for Message Transfer Priorities
Reviewer: S. Moonesamy
Review Date: May 21, 2012
IETF Last Call Date: May 28, 2012

Summary:  This draft is ready for publication as a Proposed Standard.

This memo defines an extension to the SMTP service whereby messages 
are sent with a priority to enable receivers to take this into 
account.  The draft is well-written.

Major issues: None

Minor issues:

In Section 10:

I could have classified this under nits.  The authors already 
understand that it is not really an issue.

   "Message Submission Agents MUST implement a policy that only allows
    authenticated users (or only certain groups of authenticated users)
    to specify message transfer priorities, and MAY restrict maximum
    priority values different groups of users can request, or MAY
    override the priority values specified by MUAs."

I would have used a "SHOULD only allow authenticated users" and 
explain that there is a policy override.  It's to get around the 
"MUST implement a policy".  I think what you want to say here is to 
implement a setting that is customizable.  You also get a default 
where SMTP clients cannot abuse the feature.  I am ok with a "no text change".

Nits:

I recommend taking anything beyond this point off-list if feedback is 
desired.  Nits do not have to be addressed as it is an editorial decision.

In the Abstract:

   "This memo defines an extension to the SMTP (Simple Mail Transfer
    Protocol) service"

You don't really need to expand SMTP.

In Section 1:

   "This specification defines this mechanism by specification of
    an SMTP [RFC5321] extension."

The term "service extension" is generally used.

In Section 2:

   'The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119] when they
    appear in ALL CAPS.'

I suggest "upper case" instead of "ALL CAPS".

In Section 3:

   "The maximum length of a MAIL FROM command line is increased by 15
    characters by the possible addition of the MT-PRIORITY keyword
    and value."

RFC 5321 uses the term "octets" instead of "characters".

In Section 4.1:

   "The SMTP server MAY also alter the message priority (to lower or to
    raise it)"

I suggest: (lower or raise it)".

The specification specifies that the service extension is valid on 
the Submission port.  I don't see this mentioned in the IANA 
Considerations Section.  It can be done during the interaction with IANA.

Appendix C:

  "Communication systems used during an emergency or disaster are
   realized in several forms."

I'll suggest:

   There are several forms of communication systems used during an emergency
   or disaster.

Regards,
S. Moonesamy

v2.23.0 | Report a Bug | By Email