Simple Mail Transfer Protocol Extension for Message Transfer Priorities
draft-melnikov-smtp-priority-21

[Ballot discuss]
Updating for (-17)

1) (addressed)

2) (addressed)

3) Section 5.4 restricts MTAs from rejecting messages based on priority or priority+size (arguing that only MSAs should do so). Why is this particular kind of rejection being treated differently than other kinds of rejections at MTAs? Is there a general requirement to avoid these bounces in another document you can point to instead? If not, a discussion of the tradeoffs of a policy that would result in a rejection seems more appropriate than a normative restriction to not reject.

(update for -17) Not quite addressed yet. Alexey proposes deleting the paragraph with this restriction in it, which would address the concern.


4) (dropped)

5) (addressed)

[Ballot discuss]
Updated DISCUSS based on -17:

>>> Please clarify this in the text.
>>>
>>> This mechanism can even increase the queue length at a MTA, if high
>>> priority messages arrive at the same rate (or even higher) than the
>>> outgoing rate from that MTA.
>>
>> Assuming the overhead of processing a high priority message is
>> negligible, I don't think that is true. The queue length at the MTA
>> will increase because the incoming rate is higher than outgoing. This
>> is not priority specific.

My point is that it becomes an issue if the processing of high priority messages is not negligible for whatever reason, e.g., if this message is rather big and it takes a long time to transmit it on the outgoing link.

However, I do not have recommendation on how to handle this situation potentially caused by this extension other than adding a warning along the line that an operator of an MTA using this extension should monitor the outgoing queue in terms of queue length, number of high priority messages queued, and number of high priority messages arriving per time interval.

[Ballot discuss]
The document talks about end-to-end use across a mix of MTAs that do or do-not support the extensions, but not across MTAs with different administrators.  The applicability of this mechanism would seem to apply only to a single "domain" of administration, where control of incoming messages at the edge can be performed to make sure the system isn't abused.  I think the same problems from interdomain IP QoS apply here as the initial MTA where the priority was approved may not be able to tell if it will be approved all the way across the path of other MTAs to the destination.

[Ballot discuss]
1) There is some tension between the requirements in Sections 4.1 and 4.2
(highlighted by a requirement in Section 10).

Section 4.1 says "The SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy."

Section 10 reinforces that MTAs "MAY override the priority values"

But Section 4.2 to take the results of 4.1 (which includes the possibility of changing the message priority), but goes on to say:

"For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if that value is not supported (as a distinct priority value) by the MTA's implementation of this extension."

This appears to be a conflict. Would it better capture the intent to change that last sentence to sat "only because that value is not supported" instead of "if that value is not supported"? If so, I suggest rewriting the sentence without using the 2119 MUST NOT. Would the following work? (Adam Roach put this together):

"An MTA that supports the MT-PRIORITY extension MUST include an MT-PRIORITY parameter whenever it relays a message to an MTA or MDA that also supports the MT-PRIORITY extension. The MTA sets the value of the MT-PRIORITY parameter according to its local policy. In the absence of a policy-based reason for adjusting the value, the MTA SHOULD set the MT-PRIORITY parameter to the value determined from the procedure described in section 4.1. Note that this value might be different than the priority level at which the MTA actually handles the request, due to the rounding described in section 5."

Section 5 also reiterates this MUST and might need to be adjusted to match.


2) Amplifying Stephen's almost-discuss: Do we really want to preempt real messages in favor of DSNs? If so, are there security considerations specific to DSNs that this document should point to (that would discuss how to mitigate large numbers of malicious DSNs)?

3) Section 5.4 restricts MTAs from rejecting messages based on priority or priority+size (arguing that only MSAs should do so). Why is this particular kind of rejection being treated differently than other kinds of rejections at MTAs? Is there a general requirement to avoid these bounces in another document you can point to instead? If not, a discussion of the tradeoffs of a policy that would result in a rejection seems more appropriate than a normative restriction to not reject.

4) What discourages an MUA (the UA, not the user) that gets a rejection stating that its priority was too low from immediately resubmitting the request with a higher priority? Is there anything that discourages a user from doing so?

5) (The clarification the Transport ADs have asked for may obviate this). Can the document clarify why and when an MTA would want to open a new connection for sending higher priority messages? If it has a connection already, why wouldn't it just use that? If there's no transport congestion, and the queues behind the existing connection are backing up, how is opening a new connection going to help? If there _is_ transport congestion, opening a new connection is going to hurt.

[Ballot comment]
Updated #4 based on some IMs with Alexey:

0) BTW - my initial thought about this draft was "I wish I had of thought of this ten yeas ago."  Really hoped you'd go all the way and have different precedences/priorities for the to and cc recipients ;)

1) App A: Actually ACP123/STANAG 4406 specifies a range from 0-31.  And (this relates to the discuss) if somebody specifies four more values higher than override how will the mapping get done?

2) App A: In 123/4406, there's priority and precedence.  The values you list are from precedence so I assume you're talking about those values and not the urgent, routine, and non-urgent values for priority.  App A says priority though:

  Military Messaging as specified in ACP 123 [ACP123] (also specified
  in STANAG 4406 [STANAG-4406]) defines six priority values.

3) App B contains the following:

  Where SMTP is used to support military messaging, the following
  mappings SHOULD be used.

Should this say mixer instead of military messaging?

4) I'm trying to wrap my head around why if you go from MMHS to SMTP you'd map urgent and flash to different level but if you went through MIXER to get to SMTP you'd get flash and override mapped to the same level (urgent)

And, what do you do if both primary-precedence and mixer priority are there?

[Ballot comment]

- (An almost "discuss"): 4.6 means that anyone who is ok to
send me a prio=9 message can cause me to send a whole bunch of
prio=9 messages (as DSNs). Is that not a new DoS vector?
Please explain why not.

(The rest are not near-discusses btw.)

- The writeup is somewhat coy about the use-case. Its military
messaging, ala STANAG 4406/ACP 123.

- I don't get why the EHLO keyword has no parameters.  I'd
have thought that a parameter there could be a useful way to
signal some semantics for MT-PRIORITY values. Maybe that was
discussed before though. (I've not kept up with all the mail
on this draft btw.)

- I agree that the "untrusted source" concept in 4.1 seems
broken and that a resolution such as that discussed via email
seems right, that is, that this is down to bilateral agreement
really rather than being tied to SMTP AUTH so directly.

- Is 4.3 really needed? Seems like its not about relaying but
is generally true.

- What exactly does "retain" mean in 4.4? I guess it means
that the MLA MUST forward the mail with the same MT-PRIORITY
value to any next-hop that supports it. But what if only 50%
of the next-hops for a given message support this?

- I don't get what X.3.TBD2 means at the end of p7.  (I even
looked at 2034 and still don't get it.)

- Saying its "important" for MUAs to support this spec seems
over-stated. If you want to keep the term "important" then I
guess it'd be good to specify to whom what is important? (Not
all players in this space have commensurate interests.)

- 5.1, possible nit, possible significant comment. A lower
priority message could be sent first with advantage to all.
If e.g. the sending MTA knows that sending the higher priority
message over a later, but "better", interface, e.g. that is
currently down. This is a familiar concept when dealing with
contacts in DTNs. I think maybe it'd be better to talk about
trying to get the mail delievered earlier rather than the
speciifics of how priorities map to sending things from
queues.

[Ballot discuss]
Is it appropriate for the IETF to recommend the mappings for others (thinking here mostly about MMHS and NS/EP values) in App A and C?  Seems like we ought to define the mechanism and then somebody representing those communities defines what values they want?

[Ballot comment]
0) BTW - my initial thought about this draft was "I wish I had of thought of this ten yeas ago."  Really hoped you'd go all the way and have different precedences/priorities for the to and cc recipients ;)

1) App A: Actually ACP123/STANAG 4406 specifies a range from 0-31.  And (this relates to the discuss) if somebody specifies four more values higher than override how will the mapping get done?

2) App A: In 123/4406, there's priority and precedence.  The values you list are from precedence so I assume you're talking about those values and not the urgent, routine, and non-urgent values for priority.  App A says priority though:

  Military Messaging as specified in ACP 123 [ACP123] (also specified
  in STANAG 4406 [STANAG-4406]) defines six priority values.

3) App B contains the following:

  Where SMTP is used to support military messaging, the following
  mappings SHOULD be used.

Should this say mixer instead of military messaging?

4) (this gets a little bit at the discuss) App A/B: ACP 123 (at least the one duck duck go returned) includes a mapping between military precedence and civilian priority (assume this is X.411's Priority) and it maps deferred and routine to non-urgent, priority and immediate to normal, and flash and override to urgent.  How does this line up with what's in App A and B?  Seems like we ought to map the way they wanted it?

[Ballot discuss]
The document talks about end-to-end use across a mix of MTAs that do or do-not support the extensions, but not across MTAs with different administrators.  The applicability of this mechanism would seem to apply only to a single "domain" of administration, where control of incoming messages at the edge can be performed to make sure the system isn't abused.  I think the same problems from interdomain IP QoS apply here as the initial MTA where the priority was approved may not be able to tell if it will be approved all the way across the path of other MTAs to the destination.


In the case where there are multiple MX records, I believe this document is only advocating continuing to use the record that was selected based on the RFC 5321 algorithm (using the specified record priority, or randomly within a single priority) and doesn't attempt to "balance load" across them.  The assumption here must be that the network resource bottleneck is shared between this MTA and the multiple potential next-hops.  If there's a situation where there isn't a shared bottleneck, however, this assumption will not lead to optimal behavior, and I think the topic should at least be touched upon and discussed somewhat.

[Ballot comment]
I agree with Martin's DISCUSS point that in Section 5.1, "congestion" refers to existence of a queue at the application layer, and does not have anything to do with network-layer congestion which should probably be clarified.

[Ballot discuss]
I have a DISCUSS about this paragraph and the benefit of this mechanism:

Section 5.1., paragraph 6:

>    This extension provides benefits in networks with limited available
>    bandwidth or long round trip times, when the actual message transfer
>    over the network can create a significant portion of the overall
>    message delivery time from a sender to a recipient.  It is also
>    useful in case of a congestion, for example resulting from an MTA
>    queue build-up.  When neither of the two conditions mentioned above
>    is true, the use of the MT-PRIORITY SMTP extension will not result in
>    a better SMTP service.

Congestion is there if the incoming rate is higher than the outgoing rate on a bottleneck. How does this mechanism help when there is congestion?
This isn't clear to me at all.

First of all, this seems to be talking about congestion on the SMTP level and not necessarily at the transport level.
Please clarify this in the text.

This mechanism can even increase the queue length at a MTA, if high priority messages arrive at the same rate (or even higher) than the outgoing rate from that MTA. This situation would also occur without the priority mechanism, but the mechanism can make the situation even worse for lower priority messages. The will be queued up and potentially starve to death in the queue, if higher priorty messages keep arriving and they are being jumped to the front or
near front of the queue.

I do not see that it is safe to state that this mechanism will help in congestion at the SMTP level.

Further, how is the queue to be managed with the different priority levels?

[Ballot comment]
- I agree with Adrian about the really high number of priority levels

- What do the priority level mean in a multi-domain scenario, i.e., two domains can have a completely different understanding about what a particular level means.

- Section 6., paragraph 0:

>    Unextended SMTP does not offer a service for timely delivery.  The
>    "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>    [RFC2852] is an example of an SMTP extension providing a service that
>    can be used to implement such constraints.  But note that use of the
>    DELIVERBY extension alone does not guarantee any priority processing.

Does this extension allow timely delivery?
Or is it simply trying to enhance timely delivery?
And what is timely delivery?
I don't see how this is offering a service for timely delivery in all circumstances.

[Ballot discuss]
I have a DISCUSS about this paragraph and the benefit of this mechanism:

Section 5.1., paragraph 6:

>    This extension provides benefits in networks with limited available
>    bandwidth or long round trip times, when the actual message transfer
>    over the network can create a significant portion of the overall
>    message delivery time from a sender to a recipient.  It is also
>    useful in case of a congestion, for example resulting from an MTA
>    queue build-up.  When neither of the two conditions mentioned above
>    is true, the use of the MT-PRIORITY SMTP extension will not result in
>    a better SMTP service.

Congestion is there if the incoming rate is higher than the outgoing rate
on a bottleneck. How does this mechanism help when there is congestion?
This isn't clear to me at all.

First of all, this seems to be talking about congestion on the SMTP level
and not necessarily at the transport level. Please clarify this in the text.

This mechanism can even increase the queue length at a MTA, if high
priority messages arrive at the same rate (or even higher) than the outgoing
rate from that MTA.
This situation would also occur without the priority mechanism, but the
mechanism can make the situation even worse for lower priority messages.
The will be queued up and potentially starve to death in the queue, if higher
priorty messages keep arriving and they are being jumped to the front or
near front of the queue.

I do not see that it is safe to state that this mechanism will help in congestion
at the SMTP level.

Further, how is the queue to be managed with the different priority levels?

[Ballot comment]
- I agree with Adrian about the really high number of priority levels

- What do the priority level mean in a multi-domain scenario, i.e., two domains can have a completely different understanding about what a particular level means.

- Section 6., paragraph 0:

>    Unextended SMTP does not offer a service for timely delivery.  The
>    "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>    [RFC2852] is an example of an SMTP extension providing a service that
>    can be used to implement such constraints.  But note that use of the
>    DELIVERBY extension alone does not guarantee any priority processing.

Does this extension allow timely delivery? Or is it simply trying to enhance
timely delivery? And what is timely delivery?
I don't see how this is offering a service for timely delivery in all circumstances.

[Ballot discuss]
I have a DISCUSS about this paragraph and the benefit of this mechanism:

Section 5.1., paragraph 6:

>    This extension provides benefits in networks with limited available
>    bandwidth or long round trip times, when the actual message transfer
>    over the network can create a significant portion of the overall
>    message delivery time from a sender to a recipient.  It is also
>    useful in case of a congestion, for example resulting from an MTA
>    queue build-up.  When neither of the two conditions mentioned above
>    is true, the use of the MT-PRIORITY SMTP extension will not result in
>    a better SMTP service.

Congestion is there if the incoming rate is higher than the outgoing rate on a
bottleneck. How does this mechanism help when there is congestion? This isn't
clear to me at all.

First of all, this seems to be talking about congestion on the SMTP level and not
necessarily at the transport level. Please clarify this in the text.

This mechanism can even increase the queue length at a MTA, if high priority
messages arrive at the same rate (or even higher) than the outgoing rate from
that MTA.
This situation would also occur without the priority mechanism, but the mechanism
can make the situation even worse for lower priority messages. The will be queued
up and potentially starve to death in the queue, if higher priorty messages keep
arriving and they are being jumped to the front or near front of the queue.

I do not see that it is safe to state that this mechanism will help in congestion at the#
SMTP level.

Further, how is the queue to be managed with the different priority levels?

[Ballot comment]
- I agree with Adrian about the really high number of priority levels

- What do the priority level mean in a multi-domain scenario, i.e., two domains can have a completely different understanding about what a particular level means.

- Section 6., paragraph 0:

>    Unextended SMTP does not offer a service for timely delivery.  The
>    "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>    [RFC2852] is an example of an SMTP extension providing a service that
>    can be used to implement such constraints.  But note that use of the
>    DELIVERBY extension alone does not guarantee any priority processing.

  Does this extension allow timely delivery? Or is it simply trying to enhance timely delivery?
  I don't see how this is offering a service for timely delivery in all circumstances.

[Ballot comment]
I have no objection to the publication of this document.

---

Are you sure you have not conflated priority and importance?
High priority messages need to be delivered quickly and an
implementation may want to let them overtake lower priority messages.
High importance messages need to be delivered (eventually) and should
have a lower chace of being dropped.

4.1 with its ability to reject low priority messages appears to be
doing importance.

---

Appendix E gives some motivations for 19 priorities. It seems like a
very large number to me. Experience with this sort of range of options
and priority levels suggests that it only adds confusion. I suppose my
question is: are you sure?

UPDATED PROTO writeup for draft-melnikov-smtp-priority-16

The publication of draft-melnikov-smtp-priority as a Proposed Standard is requested by an individual contributor.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document proposes a standard protocol extension to SMTP.  The shepherd and the participants in the discussion of the document believe that Proposed Standard is correct, and title page header says "Standards Track".

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This defines an extension to SMTP whereby messages are sent with a "priority", enabling the receiving Message Transfer Agent to take the priority into account for onward processing.  The goal is to process and/or transfer higher priority messages first.

Working Group Summary

  Was the document considered in any WG, and if so, why was
  it not adopted as a work item there? Was there controversy
  about particular points that caused the WG to not adopt the
  document?

There are currently no appropriate email-related working groups.  The ADs and AppsAWG chairs considered the document for the Apps Area WG, but decided that it would be done best as an individual submission, and did not need the attention of the working group.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are at least 3 existing MTAs that implement multiple priority levels internally, and which currently detect priorities from various header fields (in non-standard ways).  These implementations can benefit from this SMTP extension.  There is at least one prototype implementation, and plans for at least one other after publication.  This is largely being done for a particular use case, and the proponents are aware of some of the tradeoffs they've made.  The shepherd has some concern about the broader applicability of this as a standard, given those trade-offs.  That said, some of them had to be made, and there is value in implementing features from proprietary email systems in standardized ways on the open Internet.  The shepherd supports that general effort.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Barry Leiba is the document shepherd; Pete Resnick is the Responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed several versions of the document as it has progressed through the stages of discussion and modification, and I think this version is ready to go forward.  With the split of the parameter tunneling into a separate (experimental) document, the only concern that remains for me involves issues with the trust model (see below).

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has had sufficient review from the email community, on the ietf-smtp list and through individual reviews.  I have no concerns about the level of review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I would like to see SecDir and OpsDir reviews during the last-call process.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

There is a trust issue involved here: an MUA, an MSA, or an MTA is asking a subsequent MTA (or MSA) to accept a request to give a message priority handling.  The document makes it clear that some level of trust is needed before accepting that, but it's not clear how this will work in the general case.  That said, the concept is at Proposed Standard quality.  The trust situation is more questionable when implementing the companion document's experimental extension.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

No, and there are no known IPR issues with this document.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

The consensus for this is solid, but relatively small.  A number of participants/reviewers have expressed interest in the concept, though it's not clear how much implementation is planned.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document refers to iana.org URLs at the shepherd's request, to make it clear which registries are being referenced.  These URLs will be removed before RFC publication.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews are needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There is a normative reference to RFC 2033 (LMTP), which is Informational.  This needs to be called out in the last-call note.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No documents are modified by this one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document contains several IANA actions, which are all clearly specified and correct.  No new registries are created.  There are TBD items that will be assigned by IANA after approval.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

I have run the usual idnits and ABNF checks, and all is OK.

IANA has reviewed draft-melnikov-smtp-priority-13 and has the following comments:

ICANN understands that, upon approval of this document, there are three IANA actions which must be completed.

- First, in the SMTP Service Extensions registry of the Mail Parameters registry at:

http://www.iana.org/assignments/mail-parameters

the following SMTP Service Extension will be added:

Keywords: MT-PRIORITY
Description: Message Transfer Priorities
Reference: [ RFC-to-be ]
Note:

- Second, in the Additional-registered-clauses of the Mail Parameters registry at

http://www.iana.org/assignments/mail-parameters

the following Additional registered clauses will be added as follows:

Clause name: PRIORITY
Syntax summary: See Section 6 of [ RFC-to-be ]
Description: Records the value of the MT-PRIORITY parameter specified in
the MAIL FROM command
Reference: [ RFC-to-be ]

- Third, in the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xml

three Enumerated Status Codes will be added as follows:

Code: X.7.TBD1
Sample Text: Priority Level is too low
Associated basic status code: 450, 550 (other 4XX or 5XX codes are allowed)
Description: The specified priority level is below the lowest priority
acceptable for the receiving SMTP server. This condition might be
temporary, for example the server operating in a mode where only high
priority messages are accepted for transfer and delivery.
Reference: RFC [ RFC-to-be ]
Submitter: A. Melnikov
Change controller: IESG

Code: X.3.TBD2
Sample Text: Message is too big for the specified priority
Associated basic status code: 552 (other 4XX or 5XX codes are allowed)
Description: The message is too big for the specified priority.
This condition might be temporary, for example the server is operating
in a mode where only high priority messages are accepted for transfer
and delivery.
Reference: RFC [ RFC-to-be ]
Submitter: A. Melnikov
Change controller: IESG

Code: X.3.TBD3
Sample Text: Requested priority was downgraded
Associated basic status code: 250 or 251
Description: The message mas accepted for relay/delivery, but the
requested priority can't be honoured and was downgraded. The human
readable text after the status code contains the new priority, followed
by SP (space) and explanatory
human readable text.
Reference: RFC [ RFC-to-be ]
Submitter: A. Melnikov
Change controller: IESG

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: SECOND Last Call:  (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Simple Mail Transfer Protocol extension for Message Transfer
  Priorities'
  as Proposed Standard

A Last Call was made previously for this document, and the Last Call
comments resulted in a substantial rewrite, separating out some
work into a separate draft (draft-melnikov-smtp-priority-tunneling-00),
which will be send out for a separate Last Call soon.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-05-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines an extension to the SMTP (Simple Mail Transfer
  Protocol) service whereby messages are sent with a priority to enable
  receivers to take this into account for onward processing, with the
  general goal of processing and/or transferring higher priority
  messages first.

Note that there is a down-reference in this document: There is a normative reference to RFC 2033 (LMTP), which is Informational.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-melnikov-smtp-priority/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-melnikov-smtp-priority/ballot/


No IPR declarations have been submitted directly on this I-D.

ICANN understands that, upon approval of this document, there are four
IANA actions which must be completed.

First, in the SMTP Service Extensions registry of the Mail Parameters
registry at:

http://www.iana.org/assignments/mail-parameters

the following SMTP Service Extension will be added:

Keywords: MT-PRIORITY
Description: Message Transfer Priorities
Reference: [ RFC-to-be ]
Note:

Second, in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

the following two message header field name will be added as follows:

Header field name: MT-Priority
Protocol: mail
Status: standard
Reference: [ RFC-to-be ]

Third, in the Additional-registered-clauses of the Mail Parameters
registry at

http://www.iana.org/assignments/mail-parameters

the following Additional registered clauses will be added as follows:

Clause name: PRIORITY
Syntax summary: See Section 6 of [ RFC-to-be ]
Description: Records the value of the MT-PRIORITY parameter specified in
the MAIL FROM command
Reference: [ RFC-to-be ]

Fourth, in the Simple Mail Transfer Protocol (SMTP) Enhanced Status
Codes Registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xml

two Enumerated Status Codes will be added as follows:

Code: X.7.TBD1
Sample Text: Priority Level is too low
Associated basic status code: 450, 550 (other 4XX or 5XX codes are allowed)
Description: The specified priority level is below the lowest priority
acceptable for the receiving SMTP server. This condition might be
temporary, for example the server operating in a mode where only high
priority messages are accepted for transfer and delivery.
Reference: RFC [ RFC-to-be ]
Submitter: A. Melnikov
Change controller: IESG

Code: X.3.TBD2
Sample Text: Message is too big for the specified priority
Associated basic status code: 552 (other 4XX or 5XX codes are allowed)
Description: The message is too big for the specified priority.
This condition might be temporary, for example the server is operating
in a mode where only high priority messages are accepted for transfer
and delivery.
Reference: RFC [ RFC-to-be ]
Submitter: A. Melnikov
Change controller: IESG

Code: X.3.TBD3
Sample Text: Requested priority was downgraded
Associated basic status code: 250 or 251
Description: The message mas accepted for relay/delivery, but the
requested priority can't be honoured and was downgraded. The human
readable text after the status code contains the new priority, followed
by SP (space) and explanatory
human readable text.
Reference: RFC [ RFC-to-be ]
Submitter: A. Melnikov
Change controller: IESG

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Reply-To: ietf@ietf.org

Subject: Last Call:  (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard





The IESG has received a request from an individual submitter to consider

the following document:

- 'Simple Mail Transfer Protocol extension for Message Transfer

  Priorities'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-03-28. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This memo defines an extension to the SMTP (Simple Mail Transfer

  Protocol) service whereby messages are sent with a priority to enable

  receivers to take this into account for onward processing, with the

  general goal of processing and/or transferring higher priority

  messages first.



Note that there is a down-reference in this document: There is a normative reference to RFC 2033 (LMTP), which is Informational.



The file can be obtained via

http://datatracker.ietf.org/doc/draft-melnikov-smtp-priority/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-melnikov-smtp-priority/ballot/





No IPR declarations have been submitted directly on this I-D.

PROTO writeup for draft-melnikov-smtp-priority-07

The publication of draft-melnikov-smtp-priority as a Proposed Standard is requested by an individual contributor.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document proposes a standard protocol extension to SMTP.  It is possible for the proposal to go through as Experimental, but the shepherd and the participants in the discussion of the document believe that Proposed Standard is correct.  The strongest argument for Experimental is probably the new mechanism of tunneling the SMTP parameters through servers that don't support them by using reserved message header fields (see more below).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This defines an extension to SMTP whereby messages are sent with a "priority", enabling the receiving Message Transfer Agent to take the priority into account for onward processing.  The goal is to process and/or transfer higher priority messages first.

Working Group Summary

  Was the document considered in any WG, and if so, why was
  it not adopted as a work item there? Was there controversy
  about particular points that caused the WG to not adopt the
  document?

There are currently no appropriate email-related working groups.  The ADs and AppsAWG chairs considered the document for the Apps Area WG, but decided that it would be done best as an individual submission, and did not need the attention of the working group.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is at least one prototype implementation, and plans for at least one other after publication.  This is largely being done for a particular use case, and the proponents are aware of some of the tradeoffs they've made.  The shepherd has some concern about the broader applicability of this as a standard, given those trade-offs.  That said, some of them had to be made, and there is value in implementing features from proprietary email systems in standardized ways on the open Internet.  The shepherd supports that general effort.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Barry Leiba is the document shepherd; Pete Resnick is the Responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed several versions of the document as it has progressed through the stages of discussion and modification, and I think this version is ready to go forward.  I would like IETF community input on some of the trade-offs, particularly those created by the parameter tunneling and those involving the trust model (see below).

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has had sufficient review from the email community, on the ietf-smtp list and through individual reviews.  I have no concerns about the level of review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I would like to see SecDir and OpsDir reviews during the last-call process.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

The most significant item that needs to be called out is the issue of tunneling the PRIORITY value through non-conforming MTAs by turning it into a message header field (MT-Priority) and then back again.  This is a problematic technique, but is an important capability for those who need and intend to implement this extension.  It creates a trust issue, wherein a message containing MT-Priority can be originated with a Message Submission Agent that does not know about this extension, and when the message hits a Message Transfer Agent that does support this, the header field will be turned back into a valid PRIORITY value, on the unwarranted assumption that it was authorized.  Intermediate MTAs have no way to distinguish this situation from one where the field was tunneled legitimately.

The counter-argument is that the use case for this specification involves out-of-band trust relationships, and that such situations will be known and dealt with.  I believe that limits the usability of those features on the open Internet, with other use cases.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

No, and there are no known IPR issues with this document.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

The consensus for this is solid, but relatively small.  A number of participants/reviewers have expressed interest in the concept, though it's not clear how much implementation is planned.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document refers to iana.org URLs at the shepherd's request, to make it clear which registries are being referenced.  These URLs will be removed before RFC publication.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews are needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There is a normative reference to RFC 2033 (LMTP), which is Informational.  This needs to be called out in the last-call note.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No documents are modified by this one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document contains several IANA actions, which are all clearly specified and correct.  No new registries are created.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

I have run the usual idnits and ABNF checks, and all is OK.