[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 6710

Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Standards Track                             K. Carlberg
Expires: September 5, 2011                                           G11
                                                           March 4, 2011


     Simple Mail Transfer Protocol extension for Message Priorities
                    draft-melnikov-smtp-priority-00

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 September 5, 2011.

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 September 5, 2011               [Page 1]

Internet-Draft    SMTP Extension for Message Priorities       March 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  . . . . .  6
     4.7.  Interaction with DSN SMTP Extension  . . . . . . . . . . .  7
   5.  The Priority Service Extension . . . . . . . . . . . . . . . .  7
     5.1.  Expedited Transfer . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.  Probability  . . . . . . . . . . . . . . . . . . . . .  8
       5.1.2.  Preemption of sessions or transactions . . . . . . . .  8
     5.2.  Timely Delivery  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Syntax of the MT-Priority header field . . . . . . . . . . . .  9
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Open Issues/ToDo . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Mapping of PRIORITY parameter values for Military
                Messaging . . . . . . . . . . . . . . . . . . . . . . 12
   Appendix B.  Mapping of PRIORITY parameter values for MIXER  . . . 13
   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13


















Melnikov & Carlberg     Expires September 5, 2011               [Page 2]

Internet-Draft    SMTP Extension for Message Priorities       March 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 message
   delay may 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 enables this, 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 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 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.

   This document uses the phrase "an email is ready to be sent", if it



Melnikov & Carlberg     Expires September 5, 2011               [Page 3]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


   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.  If a server includes
       PRIORITY in its EHLO response, it MUST be fully compliant with
       this version of this specification.

   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 12
       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 September 5, 2011               [Page 4]

Internet-Draft    SMTP Extension for Message Priorities       March 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.  If an SMTP client issues a MAIL command containing any
       syntactically valid PRIORITY parameter, a conforming SMTP server
       MUST return the same response (and Enhanced Status Code) as it
       would to the same MAIL command without the PRIORITY parameter.  A
       conforming SMTP server MUST NOT refuse a MAIL command based on
       the presence or absence of this 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 SHOULD issue the response "501 syntax error
       in parameter" (with 5.5.2 Enhanced Status Code).

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

   The SMTP server MAY ignore or downgrade priorities from untrusted or
   insufficiently trusted sources.  Additionally, Mail Submission Agent
   (MSA) MAY alter the message priority (both to downgrade or upgrade
   it).



Melnikov & Carlberg     Expires September 5, 2011               [Page 5]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


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
       relaying the message.  (For example, the MTA therefore MUST NOT
       change the priority value if it doesn't recognize 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
   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:




Melnikov & Carlberg     Expires September 5, 2011               [Page 6]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


   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 use the same priority
   value in delivery reports (whether for successful delivery or failed
   delivery) it generates for a message with non zero priority.

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

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



Melnikov & Carlberg     Expires September 5, 2011               [Page 7]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


   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.

   Especially 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.  One example would be the use of DiffServ, RSVP 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
   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, a client must abort a running session for
   emails with lower priority no later than directly after the current
   transaction.  The client even may interrupt an active transaction and
   should do this, if otherwise constraints such as delivery time (as



Melnikov & Carlberg     Expires September 5, 2011               [Page 8]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


   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.

6.  Syntax of the MT-Priority header field

   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>








Melnikov & Carlberg     Expires September 5, 2011               [Page 9]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


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

   ToDo: Record message priority in the added Received header field?

   Open Issue: Tunneling of priority information through non conforming
   MTAs - is this something that should be standardized?  (Preference:
   yes)

   Open Issue: Should unsupported priority values cause message
   rejection instead of conversion to supported values?  (Preference:
   no)

   Open Issue: Should priority values affect maximum allowed message
   size?  (Preference: mild preference for "no")

9.  IANA Considerations

   This specification requests IANA to add the PRIORITY SMTP extension
   to the list of supported SMTP Extensions.




Melnikov & Carlberg     Expires September 5, 2011              [Page 10]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


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

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




Melnikov & Carlberg     Expires September 5, 2011              [Page 11]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


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

11.2.  Informative References

   [RFC2852]  Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
              June 2000.

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

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 September 5, 2011              [Page 12]

Internet-Draft    SMTP Extension for Message Priorities       March 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.  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











Melnikov & Carlberg     Expires September 5, 2011              [Page 13]

Internet-Draft    SMTP Extension for Message Priorities       March 2011


   Ken Carlberg
   G11
   1601 Clarendon Blvd, #203
   Arlington, VA  22209
   USA

   EMail: carlberg@g11.org.uk












































Melnikov & Carlberg     Expires September 5, 2011              [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/