Network Working Group A. Melnikov
Internet-Draft Isode Ltd
Intended status: Standards Track K. Carlberg
Expires: January 12, 2012 G11
July 11, 2011
Simple Mail Transfer Protocol extension for Message Priorities
draft-melnikov-smtp-priority-02
Abstract
This memo defines an extension to the SMTP (Simple Mail Transfer
Protocol) service whereby messages are sent with a priority to enable
the receiving MTA (Message Transfer Agent) to take this into account
for onward processing, with the general goal of processing and/or
transferring higher priority messages first.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Melnikov & Carlberg Expires January 12, 2012 [Page 1]
Internet-Draft SMTP Extension for Message Priorities July 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Definition of the Priority SMTP Extension . . . . . . . . . . 4
4. Handling of messages received via SMTP . . . . . . . . . . . . 5
4.1. Handling of the PRIORITY parameter by the receiving
SMTP server . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Determining priority of a message . . . . . . . . . . . . 5
4.3. Relay of messages to other conforming SMTP servers . . . . 6
4.4. Relay of messages to non-conforming SMTP servers . . . . . 6
4.5. Mailing lists and Aliases . . . . . . . . . . . . . . . . 6
4.6. Gatewaying a message into a foreign environment . . . . . 7
4.7. Interaction with DSN SMTP Extension . . . . . . . . . . . 7
5. The Priority Service Extension . . . . . . . . . . . . . . . . 7
5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Probability . . . . . . . . . . . . . . . . . . . . . 8
5.1.2. Preemption of sessions or transactions . . . . . . . . 9
5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 9
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Open Issues/ToDo . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Mapping of PRIORITY parameter values for Military
Messaging . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Mapping of PRIORITY parameter values for MIXER . . . 14
Appendix C. Mapping of National Security / Emergency
Preparedness (NS/EP) Values . . . . . . . . . . . . . 14
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Melnikov & Carlberg Expires January 12, 2012 [Page 2]
Internet-Draft SMTP Extension for Message Priorities July 2011
1. Introduction
Where resources for switching or transfer of messages are constrained
(e.g., bandwidth, round trip time or processing capability) it is
desirable to process high priority messages first. This is
particularly important during emergencies for first responders and
for environments such as military messaging, where messages have high
operational significance, and the consequences of extraneous delay
can be significant.
In order for an MTA to be able to send higher priority messages
first, there needs to be a mechanism to communicate on both
submission and transfer the priority of each message. This
specification defines this mechanism by specification of an SMTP
[RFC5321] extension. It also enables communication of message
priority through MTAs that are not priority aware, by definition of a
new message header field [RFC5322].
Various MUAs already use various other header field that convey
similar meaning such as message importance. Example of such header
fields are Importance [RFC2156], Priority [RFC2156] and X-Priority
(undocumented). Considering subtle differences in the meaning of
these header fields and widely different syntax, this document
defines a new header field.
2. Conventions Used in This Document
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].
The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
notation including the core rules defined in Appendix B of RFC 5234
[RFC5234].
This document uses the term "priority" in the meaning of expedited
treatment of a message by the server according to the message's
priority.
This document uses the phrase "an email is waiting to be sent", if it
resides in the outbound queue of an MTA and can be sent to the next
hop or delivered to its final recipient(s) once available resources
at the sending MTA allow this. Emails having their processing
delayed for some reason within the MTA are NOT waiting to be sent
during this delay. The most important reason for emails to be
delayed is a transient error response from the next MTA to which the
email must be transferred.
Melnikov & Carlberg Expires January 12, 2012 [Page 3]
Internet-Draft SMTP Extension for Message Priorities July 2011
This document uses the phrase "an email is ready to be sent", if it
is waiting to be sent and either no emails with higher priority are
waiting to be sent or available resources allow more emails to be
sent in parallel than the number of emails with higher priorities
that are waiting to be sent. Note that an email may be ready to be
sent but the transfer or delivery process can not yet be initiated,
because the number of emails ready to be sent exceeds the number of
emails that can be processed in parallel.
3. Definition of the Priority SMTP Extension
The following service extension is defined:
1. The textual name of this extension is "Priority Message
Handling".
2. The EHLO keyword value associated with this extension is
"PRIORITY".
3. No parameter values are defined for this EHLO keyword value. In
order to permit future (although unanticipated) extensions, the
EHLO response MUST NOT contain any parameters for that keyword.
Clients MUST ignore any parameters; that is, clients MUST behave
as if the parameters do not appear.
4. No additional SMTP verbs are defined by this extension.
5. One optional parameter ("PRIORITY") is added to the MAIL command.
The value associated with this parameter is a decimal integer
number from -99 to 99 indicating the priority of the email
message. The syntax of the PRIORITY parameter is described by
the <priority-value> ABNF non-terminal defined in Section 6. A
value of 0 indicates an email from a client/network not
supporting priorities or intended to be sent to such a server/
network; this is the same as not specifying the PRIORITY
parameter. Higher numbers mean higher priority.
6. The maximum length of a MAIL command line is increased by 13
characters by the possible addition of the PRIORITY keyword and
value.
7. The PRIORITY extension is valid for the submission service
[RFC4409] and LTMP [RFC2033].
Melnikov & Carlberg Expires January 12, 2012 [Page 4]
Internet-Draft SMTP Extension for Message Priorities July 2011
4. Handling of messages received via SMTP
This section describes how a conforming MTA should handle any
messages received via SMTP.
4.1. Handling of the PRIORITY parameter by the receiving SMTP server
The following rules apply to SMTP transactions in which the PRIORITY
parameter is used:
1. A conforming SMTP server SHOULD NOT refuse a MAIL command based
on the absence of the PRIORITY parameter. However, if any of the
associated esmtp-values are not syntactically valid, or if there
is more than one PRIORITY parameter in a particular MAIL command,
the server MUST return an error, for example "501 syntax error in
parameter" (with 5.5.2 Enhanced Status Code [RFC2034]).
Additionally, when inserting a Received header field as specified in
Section 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the
"PRI" clause which syntax is specified in Section 6.
4.2. Determining priority of a message
An SMTP server compliant with this specification can determine the
priority of a received message as follows:
1. If the sending SMTP client specified the PRIORITY parameter to
the MAIL command, then the value of this parameter is the message
priority.
2. If the sending SMTP client hasn't specified the PRIORITY
parameter to the MAIL command, but the message has a single
syntactically valid MT-Priority header field, then the value of
this header field is the message priority.
3. Otherwise (if no PRIORITY parameter to the MAIL command was
specified and the message doesn't contain a syntactically valid
MT-Priority header field, or contains multiple MT-Priority header
fields) the message has priority 0.
Other message header fields, such as Importance [RFC2156], Priority
[RFC2156] and X-Priority, MUST NOT be used for determining the
priority under this "Priority Message Handling" SMTP extension.
The SMTP server MAY ignore or downgrade priorities from untrusted
(e.g. unauthenticated) or insufficiently trusted sources.
Alternatively an SMTP server MAY reject a message based on the
determined priority. If the latter case, the server SHOULD use 450,
Melnikov & Carlberg Expires January 12, 2012 [Page 5]
Internet-Draft SMTP Extension for Message Priorities July 2011
455 or 550 reply code. The corresponding enhanced status code MUST
be X.7.TBD1 [RFC2034] if the determined priority level is below the
lowest priority acceptable for the receiving SMTP server.
Additionally, Mail Submission Agent (MSA) MAY alter the message
priority (both to lower or to upper it).
4.3. Relay of messages to other conforming SMTP servers
The following rules govern the behavior of a conforming MTA (in the
role of an SMTP client), when relaying a message which was received
via the SMTP protocol, to an SMTP server that supports the PRIORITY
SMTP extension:
1. A PRIORITY parameter with the value determined by the procedure
from Section 4.2 MUST appear in the MAIL command issued when the
message is relayed. (For example, once an MTA accepts a message,
the MTA MUST NOT change a (syntactically valid) priority value if
the MTA doesn't support it.)
2. Further processing of the PRIORITY parameter is described in
Section 5.
4.4. Relay of messages to non-conforming SMTP servers
The following rules govern the behavior of a conforming MTA (in the
role of an SMTP client), when relaying a message which was received
via the SMTP protocol, to an SMTP server that does not support the
PRIORITY SMTP extension:
1. A PRIORITY parameter MUST NOT appear in the MAIL command issued
when relaying the message.
2. The relaying MTA MUST remove any and all existing MT-Priority
header fields from the message, and then add its own MT-Priority
header field with the value determined by the procedure in
Section 4.2. Syntax of the MT-Priority header field is specified
in Section 6.
4.5. Mailing lists and Aliases
Several options exist to translate the address of an email recipient
into one or more other addresses. Examples for this are aliases and
mailing lists [RFC5321].
If a recipient address is to be translated and/or expanded when
delivered to an alias or a mailing list, the translating or expanding
entity (maillist manager, MTA etc.) SHOULD retain the original
Melnikov & Carlberg Expires January 12, 2012 [Page 6]
Internet-Draft SMTP Extension for Message Priorities July 2011
priority for all expanded and/or translated addresses.
4.6. Gatewaying a message into a foreign environment
The following rules govern the behavior of a conforming MTA, when
gatewaying a message that was received via the SMTP protocol, into a
foreign (non-SMTP) environment:
1. If the destination environment is unable to provide an equivalent
of the PRIORITY parameter, the conforming MTA SHOULD behave as if
it is relaying to a non-conformant SMTP (Section 4.4).
2. If the destination environment is capable of providing an
equivalent of the PRIORITY parameter, the conforming MTA SHOULD
behave as if it is relaying to a conformant SMTP (Section 4.3),
converting the PRIORITY parameter to the equivalent in the
destination environment.
4.7. Interaction with DSN SMTP Extension
An MTA which also conforms to [RFC3461] SHOULD apply the same
priority value to delivery reports (whether for successful delivery
or failed delivery) it generates for a message.
5. The Priority Service Extension
The priorities of messages affect the order the messages are
transfered from the client to the server. This is largely
independent from the order in which they were originally received by
the server.
An SMTP server compliant with this specification MUST be able to
support at least 6 distinct priority levels (-40, -20, 0, 20, 40,
60). However even when only implementing the 6 priority levels it
MUST treat other syntactically valid priority values as valid and MAY
map them to the next supported priority values higher than the value,
or to the priority 60 for all values above 60.
The Priority Service Extension can be combined with DELIVERBY
[RFC2852] SMTP service extension, however there is no requirement
that both extensions are always implemented together.
Some SMTP servers MAY impose additional maximum message size
contraints for different message priorities, for example messages
with priority 60 might not be larger than 4 Kb. If an SMTP server
wants to reject a message because it is too big for the determined
priority, it SHOULD use 552 or 554 reply codes, together with the
X.3.TBD2 enhanced status code [RFC2034].
Melnikov & Carlberg Expires January 12, 2012 [Page 7]
Internet-Draft SMTP Extension for Message Priorities July 2011
5.1. Expedited Transfer
The main service provided by the Priority Message Handling SMTP
Service Extension is expedited transfer of emails with a higher
priority. Therefore an SMTP client that has more than one email to
send at a given time SHOULD send those with a higher priority before
those with a lower one. Additionally, the retry interval and/or
default timeout before non-delivery report is generated MAY be lower
(more aggressive) for messages of higher priority.
This SMTP extension only allows a single priority for all recipients
of the same message.
As a default policy, emails with higher priority waiting to be sent
by a client MUST NOT initiate transactions for emails with lower
priorites. If two or more emails with the same priority are ready to
be sent at the same time, the MTA should use its regular algorithm
(the algorithm for messages with no explicit priorities) for deciding
how to send them out.
In networks with limited available bandwidth or long round trip times
the actual message transfer over the network may create a significant
portion of the overall message delivery time from a sender to a
recipient. Besides the actions taken at the application level it can
thus be important to deploy priority or precedence mechanisms offered
by the network itself to ensure timely delivery of the emails.
Examples would be the use of DiffServ [RFC2474], RSVP [RFC2205] and
the work-in-progress effort extension to RSVP that prioritizes
reservations.
Most current SMTP MTAs are capable of handling several inbound and
outbound connections at once. With this feature it should be
possible to start additional outbound connections for emails with
higher priorities even if there are already several connections
running for other emails. Two possible ways of implementing
expedited transfer are described in more details in subsections of
this section.
5.1.1. Probability
This section is Informative.
As the name suggests, probability involves increasing the chances of
obtaining resources without adversely affecting previously
established connections. One example would involve requesting
resources set aside for specific priority levels. If these
additional resources are exhausted, then the desired connection is
denied. Queues, new timers, or combinations thereof can be used to
Melnikov & Carlberg Expires January 12, 2012 [Page 8]
Internet-Draft SMTP Extension for Message Priorities July 2011
facilitate the higher priority requests, but the key is that
mechanisms focus on increasing the probability of message transfer.
5.1.2. Preemption of sessions or transactions
This section is Informative.
Preemption is a type of action that focusses only on a comparision of
priorities to determine if previously established transactions must
be displaced in favor of higher priority requests. If no additional
connection is possible, the client aborts a running session for
emails with lower priority no later than directly after the current
transaction. The client even can interrupt an active transaction and
should do so, if other constraints such as delivery time (as
specified in the DELIVERBY SMTP extension [RFC2852]) would be
violated for the email with higher priority. When interrupting an
active transaction, the client should take the total message size and
the size of the transferred portion of the message being interrupted
into consideration. This preliminary termination of sessions or
transactions is called preemption.
If preemption of running transactions occurs, the client must choose
a transaction with the lowest priority currently processed.
If the client has an option (i.e. it is supported by the next hop
MTA) to interrupt transactions in a way that it can be restarted at
the interruption point later, it should deploy it. An example for a
mechanism providing such a service is the "SMTP Service Extension for
Checkpoint/Restart" defined in [RFC1845].
If a client opts for the preemption of sessions instead of
transactions, it must preempt the next session that reaches the end
of a transaction.
5.2. Timely Delivery
An important constraint (usually associated with higher priority
levels) is, that messages with that priority have to reach its
destination within a defined period of time. In some cases, higher
priorities mean shorter maximum allowed time of delivery.
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.
Melnikov & Carlberg Expires January 12, 2012 [Page 9]
Internet-Draft SMTP Extension for Message Priorities July 2011
6. Syntax
priority-header-field = "MT-Priority:" [CFWS] priority-value [CFWS] CRLF
priority-value = (["-"] NZDIGIT [DIGIT]) / "0"
; Allowed values are from -99 to 99 inclusive
NZDIGIT = %x31-39
; "1"-"9"
CFWS = <defined in RFC 5322>
Pri = CFWS "PRI" FWS priority-value
; Complies with the <Additional-Registered-Clauses>
; non-terminal syntax from RFC 5321.
7. Example
An original SMTP transaction with 2 recipients. Note that the
example is also making use of the DELIVERBY and DSN SMTP extensions.
S: 220 example.net SMTP server here
C: EHLO example.com
S: 250-example.net
S: 250-DSN
S: 250-DELIVERBY
S: 250-PRIORITY
C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159 PRIORITY=40
S: 250 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
8. Open Issues/ToDo
[[anchor15: This section should be removed before publication]]
Open Issue: Tunneling of priority information through non conforming
MTAs - is this something that should be standardized? (Preference:
Melnikov & Carlberg Expires January 12, 2012 [Page 10]
Internet-Draft SMTP Extension for Message Priorities July 2011
yes)
9. IANA Considerations
This specification requests IANA to add the PRIORITY SMTP extension
to the list of supported SMTP Extensions.
IANA is also requested to add the following list of header fields to
the list of Permanent Message Header Fields to be used by the "mail"
protocol:
Header field: MT-Priority
Applicable protocol: mail
Status: standard
Author/change controller: Alexey Melnikov / IETF (iesg@ietf.org)
Specification document(s): [[anchor17: this document]]
This specification requests IANA to add the following new Received
header field clause to help with tracing email messages delivered
using the PRIORITY SMTP extension:
Clause name: PRI
Description: Records the value of the PRIORITY parameter specified in
the MAIL command
Syntax of the value: See Section 6 of RFCXXXX
Reference: [[anchor18: RFCXXXX]]
This specification requests IANA to add the following enhanced status
codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced Status
Codes" registry established by [RFC5248].
1. X.7.TBD1 - the determined priority level is below the minimal
priority level acceptable for the receiving SMTP server
2. X.3.TBD2 - Message is too big for the specified priority
10. Security Considerations
This document allows a message priority to be tunneled through MTAs
which don't support the PRIORITY SMTP extension by specifying how it
can be represented in the message itself (using the MT-Priority
header field). Thus it is important to ensure that an MTA receiving
a message containing the MT-Priority header field can trust that it
was set by an authorized client. Message Submission Agents can
implement a policy that only allows authenticated users (or only
certain authenticated users) to specify message priorities, and to
restrict maximum priority values different groups of users can
request, or override the priority values specified by MUAs. Such
Melnikov & Carlberg Expires January 12, 2012 [Page 11]
Internet-Draft SMTP Extension for Message Priorities July 2011
MSAs MUST strip any MT-Priority header field values that don't
satisfy this policy.
To protect MT-Priority header field from modification or insertion,
MUAs and MTAs inserting it into messages SHOULD use message header
protection mechanism such as DKIM [RFC4871].
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
11.2. Informative References
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
June 2000.
Melnikov & Carlberg Expires January 12, 2012 [Page 12]
Internet-Draft SMTP Extension for Message Priorities July 2011
[RFC1845] Crocker, D. and N. Freed, "SMTP Service Extension for
Checkpoint/Restart", RFC 1845, September 1995.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
Appendix A. Mapping of PRIORITY parameter values for Military Messaging
Military Messaging as specified in STANAG 4406 defines six priority
values. Where SMTP is used to support military messaging, the
following mappings SHOULD be used.
Recommended mapping of PRIORITY values for MMHS
+----------------+-----------+
| Priority value | MMHS name |
+----------------+-----------+
| -40 | Deferred |
| -20 | Routine |
| 0 | Priority |
| 20 | Immediate |
| 40 | Flash |
| 60 | Override |
+----------------+-----------+
Table 1
Melnikov & Carlberg Expires January 12, 2012 [Page 13]
Internet-Draft SMTP Extension for Message Priorities July 2011
Appendix B. Mapping of PRIORITY parameter values for MIXER
MIXER [RFC2156] defines the Priority header field with 3 values.
Where SMTP is used to support military messaging, the following
mappings SHOULD be used.
Recommended mapping of PRIORITY values for MIXER
+----------------------+----------------+
| MIXER Priority value | PRIORITY value |
+----------------------+----------------+
| non-urgent | -40 |
| normal | 0 |
| urgent | 40 |
+----------------------+----------------+
Table 2
Appendix C. Mapping of National Security / Emergency Preparedness
(NS/EP) Values
Communication systems used during an emergency or disaster are
realized in several forms. The most well known form involves the
many-to-one model of the general public contacting a public safety
access point via 911/999/112 calls through the public telephone
network. Typically, these calls do not require authorization, nor do
they invoke any prioritization.
Another form of emergency communications involves a set of authorized
users or nodes that use prioritized services to help established and
continue communication given limited available resources. [RFC4190]
includes descriptions of several systems that have been developed to
support National Security / Emergency Preparedness (NS/EP). These
deployed systems require a form of authentication and have focused on
prioritization of telephony based services. They have also been
designed as a binary form (on/off) of signaled priority
communications.
[RFC4412] includes examples of a more expansive view of NS/EP
communications in which priority migrates from a single on/off bit
value to one that comprises five priority values. This is shown in
the cases of the ETS and WPS Namespaces. Given a lack of pre-
existing NS/EP values assigned for email, we follow the paradigm of
the ETS and WPS Namespaces and recommend five ascending values shown
in the table below.
Melnikov & Carlberg Expires January 12, 2012 [Page 14]
Internet-Draft SMTP Extension for Message Priorities July 2011
+----------------+------------------+
| Priority value | Relational Order |
+----------------+------------------+
| -20 | Lowest Priority |
| 0 | ---------- |
| 20 | ---------- |
| 40 | ---------- |
| 60 | Highest Priority |
+----------------+------------------+
As in the case of Appendix A and B, the gap in numeric values listed
in this table provides room for future changes to expand the set of
priorities at a future date, or in a local and non-standardized
manner.
Appendix D. Acknowledgements
This document copies lots of text from
draft-schmeing-smtp-priorities-04.txt and
draft-schmeing-smtp-priorities-05.txt. So the authors of this
document would like to acknowledge contributions made by the authors
of draft-schmeing-smtp-priorities: Michael Schmeing and Jan-Wilhelm
Brendecke.
Many thanks for input provided by Steve Kille, David Wilson, John
Klensin, Dave Crocker, Graeme Lunt and Barry Leiba.
Authors' Addresses
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Ken Carlberg
G11
1601 Clarendon Blvd, #203
Arlington, VA 22209
USA
EMail: carlberg@g11.org.uk
Melnikov & Carlberg Expires January 12, 2012 [Page 15]
