newer spec of the manage sieve protocoll uploaded

1 files changed, 490 insertions, 433 deletions

diff --git a/docs/draft-martin-managesieve-04.txt b/docs/draft-martin-managesieve-06.txt
index 3795ba36..6deab9c1 100644
--- a/docs/draft-martin-managesieve-04.txt
+++ b/docs/draft-martin-managesieve-06.txt
@@ -1,36 +1,42 @@
+Network Working Group                                         Tim Martin
+Document: draft-martin-managesieve-06.txt                 Mirapoint Inc.
+Expires: August 2006                                     Alexey Melnikov
+                                                           Isode Limited
+                                                           February 2006
 
 
+               A Protocol for Remotely Managing Sieve Scripts
 
+                      <draft-martin-managesieve-06.txt>
 
+Status of this Memo
 
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
 
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
 
-Network Working Group                                         Tim Martin
-Document: draft-ietf-managesieve-03.txt                   Mirapoint Inc.
-Expires January 21, 2003                                    16 July 2002
-
-
-               A Protocol for Remotely Managing Sieve Scripts
-
-                      <draft-martin-managesieve-04.txt>
+   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."
 
-Status of this Memo
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
 
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC2026.  Internet-Drafts are
-    working documents of the Internet Engineering Task Force (IETF), its
-    areas, and its working groups.  Note that other groups may also
-    distribute working documents as Internet-Drafts.
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
 
-    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."
+   Distribution of this memo is unlimited.
 
-    To view the list Internet-Draft Shadow Directories, see
-    http://www.ietf.org/shadow.html.
+Copyright Notice
 
-    Distribution of this memo is unlimited.
+   Copyright (C) The Internet Society (2006).
 
 
 Abstract
@@ -42,33 +48,13 @@ Abstract
     a remote server.  This protocol allows a user to have multiple
     scripts, and also alerts a user to syntactically flawed scripts.
 
-    This an interim measure as it is hoped that eventually Sieve scripts
-    will be stored on ACAP. This document is intended to proceed on the
-    experimental track.
-
-
-
-
-
-
-
-
-
-
-
-Expires January 21, 2003        Martin                          [Page 1]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
 
                            Table of Contents
 
 
 
 Status of this Memo  . . . . . . . . . . . . . . . . . . . . . . . .   1
-
 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
-
 1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 1.1.   Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
 1.2.   Conventions Used in the Document  . . . . . . . . . . . . . .   4
@@ -78,7 +64,6 @@ Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
 1.6.   Quotas  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 1.7.   Script Names  . . . . . . . . . . . . . . . . . . . . . . . .   7
 1.8.   Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   7
-
 2.     Commands  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 2.1.   AUTHENTICATE Command  . . . . . . . . . . . . . . . . . . . .   8
 2.2.   STARTTLS Command  . . . . . . . . . . . . . . . . . . . . . .  10
@@ -90,94 +75,49 @@ Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
 2.8.   SETACTIVE Command . . . . . . . . . . . . . . . . . . . . . .  13
 2.9.   GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . . .  13
 2.10.   DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . .  14
-
 3.     Sieve URL Scheme  . . . . . . . . . . . . . . . . . . . . . .  14
-
 4.     Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  15
-
 5.     Security Considerations . . . . . . . . . . . . . . . . . . .  18
-
-6.     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
-
-7.     Copyright . . . . . . . . . . . . . . . . . . . . . . . . . .  18
-
-8.     References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
-
-9.     Author's Address  . . . . . . . . . . . . . . . . . . . . . .  19
-
-
-
-
-
-
-
-
-Expires January 21, 2003        Martin                          [Page 2]
-
-Internet Draft             Managing Sieve Scripts            July 16, 2002
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+7.     References  . . . . . . . . . . . . . . . . . . . . . . . . .
+7.1.   Normative References  . . . . . . . . . . . . . . . . . . . .
+7.2.   Informative References  . . . . . . . . . . . . . . . . . . .
+8.     Author's Address  . . . . . . . . . . . . . . . . . . . . . .
 
 
+1.  Introduction
 
 
 
+1.1.  Changes
 
+    [[Note to RFC editor: please delete this section before publication]]
 
-Expires January 21, 2003        Martin                          [Page 3]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
+    Changes since 05
+    
+    -More ABNF fixes
+    
+    -Added IANA considerations
+    
+    -Added/fixed text about AUTHENTICATE.
+    
+    -Updated the text om Sieve URLs.
+    
+    -Updated and added new examples.
+    
+    Changes since 04
 
+    -Updated boilerplate and some references. Added Alexey as co-editor.
 
-1.  Introduction
+    -Minor ABNF fixes
 
+    -Cleaned up terminology (for example, made more consistent with SASL)
 
+    -Added more examples, fixed some existing examples
 
-1.1.  Changes
+    -Clarified that STARTTLS command is optional
+    
+    -Clarified that disabling an active script when there is no script active
+     is not an error.
 
     Changes since 03
 
@@ -222,13 +162,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     -Eliminated lame PLAIN paragraph
 
-
-
-Expires January 21, 2003        Martin                          [Page 3]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
     Changes since PRE
 
     -dropped synchronized literals. added HAVESPACE command
@@ -244,8 +177,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     -added starttls support
 
 
-
-
 1.2.  Conventions Used in the Document
 
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -257,8 +188,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     "S:" exist for editorial reasons.
 
 
-
-
 1.3.  Syntax
 
     This a line oriented protocol much like [IMAP4rev1] or [ACAP]. There
@@ -275,25 +204,16 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     shown to the user and implementations MUST NOT attempt to parse the
     message for meaning.
 
-    The BYE command may be used if the server wishes to close the
+    The BYE response may be used if the server wishes to close the
     connection. A server may wish to do this because the client was idle
-
-
-
-Expires January 21, 2003        Martin                          [Page 4]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
-    too long or there were too many failed authentication attempts. This
-    command can be issued at any time and should be immediately followed
+    for too long or there were too many failed authentication attempts. This
+    response can be issued at any time and should be immediately followed
     by a server hang-up of the connection. If a server has a inactivity
     timeout resulting in client autologout it MUST be no less than 30
     minutes.
 
-    IANA registration is pending. Current implementations generally use
-    port number 2000.
-
+    <<IANA registration is pending. Current implementations generally use
+    port number 2000.>>
 
 
 1.4.  Response Codes
@@ -313,7 +233,7 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     AUTH-TOO-WEAK
 
-    This response code is returned on a tagged NO result from an
+    This response code is returned in the NO response from an
     AUTHENTICATE command. It indicates that site security policy forbids
     the use of the requested mechanism for the specified authentication
     identity.
@@ -333,14 +253,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     REFERRAL
 
     This response code may be returned with a BYE result from any
-
-
-
-Expires January 21, 2003        Martin                          [Page 5]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
     command, and includes a mandatory parameter that indicates what
     server to access to manage this user's sieve scripts.  The server
     will be specified by a Sieve URL (see "Sieve URL Scheme" section).
@@ -356,14 +268,18 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     TRANSITION-NEEDED
 
-    This response code occurs on a NO response to an AUTHENTICATE
+    This response code occurs in a NO response of an AUTHENTICATE
     command. It indicates that the user name is valid, but the entry in
     the authentication database needs to be updated in order to permit
-    authentication with the specified mechanism. This can happen if a
-    user has an entry in a system authentication database such as Unix
-    /etc/passwd, but does not have credentials suitable for use by the
-    specified mechanism.
+    authentication with the specified mechanism. This is typically done
+    by establishing a secure channel using TLS, followed by authenticating
+    once using the [PLAIN] authentication mechanism.  The selected
+    mechanism SHOULD then work for authentications in subsequent sessions.
 
+    This condition can happen if a user has an entry in a system
+    authentication database such as Unix /etc/passwd, but does not have
+    credentials suitable for use by the specified mechanism.
+    
 
     TRYLATER
 
@@ -374,7 +290,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     recognize.
 
 
-
 1.5.  Active Script
 
     A user may have multiple Sieve scripts on the server, yet only one
@@ -388,15 +303,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     else.
 
 
-
-
-
-
-Expires January 21, 2003        Martin                          [Page 6]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
 1.6.  Quotas
 
     Servers SHOULD impose quotas to prevent malicious users from
@@ -406,27 +312,29 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     quota restrictions.
 
 
-
 1.7.  Script Names
 
-    Sieve script names may contain any valid UTF8 characters, but names
-    must be at least one octet long. Script names zero octets in length
-    have special meaning. (see SETACTIVE command section) Servers MUST
-    allow names of up to 128 UTF8 octets in length, and may allow longer
+    Sieve script names may contain any valid UTF-8 characters, but names
+    must be at least one octet long. Zero octets script name
+    has special meaning (see SETACTIVE command section). Servers MUST
+    allow names of up to 128 UTF-8 octets <<(do we really want to specify
+    length in UTF-8 octets, as opposed to Unicode characters?)>>
+    in length, and may allow longer
     names.
 
 
-
 1.8.  Capabilities
 
     Server capabilities are sent by the server upon a client connection.
     Clients may request the capabilities at a later time by issuing the
     CAPABILITY command described later. The capabilities consist of a
     series of lines each with one or two strings. The first string is
-    the name of the capability. The second optional string is the value
-    associated with that capability.
+    the name of the capability, which is case-insensitive. The second
+    optional string is the value associated with that capability.
+    Order of capabilities is arbitrary, but each capability name can
+    appear at most once.
 
-    The following capabilities are defined here:
+    The following capabilities are defined in this document:
 
     IMPLEMENTATION - Name of implementation and version
 
@@ -435,7 +343,10 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     SIEVE - List of space separated Sieve extensions supported
 
-    STARTTLS - If TLS[TLS] is supported by this implementation
+    STARTTLS - If TLS [TLS] is supported by this implementation
+
+    A server implementation MUST return SIEVE and IMPLEMENTATION
+    capabilities.
 
     A client implementation MUST ignore any other capabilities given
     that it does not understand.
@@ -443,19 +354,12 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     Example:
 
     S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
-    S: "SASL" "KERBEROS_V4 GSSAPI"
+    S: "SASL" "DIGEST-MD5 GSSAPI"
     S: "SIEVE" "FILEINTO VACATION"
-
-
-
-Expires January 21, 2003        Martin                          [Page 7]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
     S: "STARTTLS"
     S: OK
 
+    <<Add RENAMESCRIPT>>
 
 
 2.  Commands
@@ -465,9 +369,9 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     valid. Servers MUST reject all other commands with a NO response.
     Clients may pipeline commands (send more than one command at a time
     without waiting for completion of the first command ). However, a
-    group of commands sent together MUST NOT have a HAVESPACE command
-    anywhere but the last command in the list.
-
+    group of commands sent together MUST NOT have an AUTHENTICATE,
+    a STARTTLS or a HAVESPACE command anywhere but the last command in
+    the list.
 
 
 2.1.  AUTHENTICATE Command
@@ -479,18 +383,24 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     The AUTHENTICATE command indicates a SASL [SASL] authentication
     mechanism to the server.  If the server supports the requested
     authentication mechanism, it performs an authentication protocol
-    exchange to authenticate and identify the user.  Optionally, it also
+    exchange to identify and authenticate the user.  Optionally, it also
     negotiates a security layer for subsequent protocol interactions.
     If the requested authentication mechanism is not supported, the
-    server rejects the AUTHENTICATE command by sending a NO response.
+    server rejects the AUTHENTICATE command by sending the NO response.
 
     The authentication protocol exchange consists of a series of server
-    challenges and client answers that are specific to the
+    challenges and client responses that are specific to the selected
     authentication mechanism.  A server challenge consists of a string
-    followed by an endline. The contents of the string is a base-64
-    encoding of the SASL data. The client answer consists of a string
-    with the base-64 encoding of the SASL data followed by an endline.
-    If the mechanism dictates that the final response be sent by the
+    (quoted or literal) followed by a CRLF. The contents of the string is
+    a base-64 encoding of the SASL data. A client response consists of
+    a string (quoted or literal) with the base-64 encoding of the SASL
+    data followed by a CRLF. If the client wishes to cancel the
+    authentication exchange, it issues a string containing a single "*".
+    If the server receives such a response, it MUST reject the
+    AUTHENTICATE command by sending an NO reply.
+
+    Note that an empty challenge/response is sent as an empty string.
+    If the mechanism dictates that the final response is sent by the
     server this data MAY be placed within the data portion of the SASL
     response code to save a round trip.
 
@@ -501,94 +411,176 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     empty challenge is not sent to the client and the server uses the
     data in the initial-response argument as if it were sent in response
     to the empty challenge.  If the initial-response argument to the
-
-
-
-Expires January 21, 2003        Martin                          [Page 8]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
     AUTHENTICATE command is used with a mechanism that sends data in the
     initial challenge, the server rejects the AUTHENTICATE command by
-    sending a tagged NO response.
+    sending the NO response.
 
     The service name specified by this protocol's profile of SASL is
-    "sieve"
+    "sieve".
+    
+    Reauthentication is not supported by ManageSieve protocol's profile
+    of SASL. I.e. after a successfully completed AUTHENTICATE command,
+    no more AUTHENTICATE commands may be issued in the same session.
+    After a successful AUTHENTICATE command completes, a server MUST
+    reject any further AUTHENTICATE commands with a NO reply.
 
     If a security layer is negotiated through the SASL authentication
     exchange, it takes effect immediately following the CRLF that
     concludes the authentication exchange for the client, and the CRLF
     of the OK response for the server.
 
-    Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL-
-    ANON]. This indicates that the server supports ANONYMOUS sieve
-    script syntax verification. Only the CAPABILITY, PUTSCRIPT and
-    LOGOUT commands are available to the anonymous user. All other
-    commands MUST give NO responses. Furthermore the PUTSCRIPT command
-    SHOULD NOT store any data. In this mode a positive response to the
-    PUTSCRIPT command indicates that the given script does not have any
-    syntax errors.
-
-    Server implementations SHOULD support authorization so that an
-    administrator can administer a user's scripts. Authorization is when
-    a user authenticates as himself but logs in as another user.
+    When a security layer takes effect, the ManageSieve protocol is reset
+    to the initial state (the state in ManageSieve after a client
+    has connected to the server).  The server MUST discard any
+    knowledge obtained from the client which was not obtained from
+    the SASL (or TLS) negotiation itself.
+    Likewise, the client MUST discard any knowledge obtained from
+    the server, such as the list of ManageSieve extensions, which
+    was not obtained from the SASL (or TLS) negotiation itself.
+    (Note that a client MAY compare the advertised SASL mechanisms before and
+    after authentication in order to detect an active down-negotiation attack.
+    See below.)
+    
+    Once a SASL security layer is established, the server MUST re-issue the
+    capability results, followed by an OK response. This is necessary to
+    protect against man-in-the-middle attacks which alter the capabilities
+    list prior to SASL negotiation.
+    The capability results MUST include all SASL mechanisms. This is done in
+    order to allow client to detect active down-negotiation attack.
+
+    When both [TLS] and SASL security layers are in effect, the
+    TLS encoding MUST be applied (when sending data) after the SASL encoding,
+    regardless of the order in which the layers were negotiated.
+
+    Server implementations SHOULD support SASL proxy authentication so
+    that an administrator can administer a user's scripts. Proxy
+    authentication is when a user authenticates as herself/himself but
+    requests the server to act (authorize) as another user.
+
+    <<The authorization identity generated by this [SASL] exchange
+    is a simple username, and both client and server MUST use the
+    [SASLprep] profile of the [StringPrep] algorithm to prepare
+    these names for transmission or comparison.  If preparation of
+    the authorization identity fails or results in an empty string
+    (unless it was transmitted as the empty string), the server
+    MUST fail the authentication.>>
 
     If an AUTHENTICATE command fails with a NO response, the client may
     try another authentication mechanism by issuing another AUTHENTICATE
     command.  In other words, the client may request authentication
     types in decreasing order of preference.
 
+    Note that a failed NO response to the AUTHENTICATE command may contain
+    one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-NEEDED or
+    TRANSITION-NEEDED. See section 1.4 for detailed description of the
+    relevant conditions.
 
+    To ensure interoperability, client and server implementations
+    of this extension MUST implement the [DIGEST-MD5] SASL
+    mechanism. <<What is the IESG policy on this?>>
 
-    Examples:
+
+    Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL-ANON].
+    This indicates that the server supports ANONYMOUS SIEVE
+    script syntax verification. Only the CAPABILITY, PUTSCRIPT and
+    LOGOUT commands are available to the anonymous user. All other
+    commands MUST give NO responses. Furthermore the PUTSCRIPT command
+    SHOULD NOT <<MUST NOT?>> store any data. In this mode a positive
+    response to the PUTSCRIPT command indicates that the given script
+    does not have any syntax errors.
+
+    Examples (Note that long lines are folded for readability and are
+              not part of protocol exchange):
 
     S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
-    S: "SASL" "KERBEROS_V4 GSSAPI"
+    S: "SASL" "DIGEST-MD5 GSSAPI"
     S: "SIEVE" "FILEINTO VACATION"
     S: "STARTTLS"
     S: OK
-    C: Authenticate "KERBEROS_V4"
-    S: "6UM4Ig=="
-    C: "BAYBQU5EUkVXLkNNVS5FRFUAOCjDCH77GOzSSOF1Df2Kb0zzPe
-    QJIrweAPyo6Q1T9xuYtCGylDqRYlbUFa77esDOtBJdDE5qRXcwHXQE5Dg
-    amqj0LqecZtKUCc8g2xpcqxn1fc/CH6QdZLOAGVpHTN1AX2Y="
-    S: "cmnEYo1x6wc="
-    C: "kjuaMkUeg2okQh+we2uiJw=="
-    S: OK
-
-
-
-
-Expires January 21, 2003        Martin                          [Page 9]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
+    C: Authenticate "DIGEST-MD5"
+    S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
+        RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
+        cnNldD11dGYtOA=="
+    C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
+        QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
+        MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
+        ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
+        ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg="
+    S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==")
+    
+    A slightly different variant of the same authentication exchange:
 
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" "DIGEST-MD5 GSSAPI"
+    S: "SIEVE" "FILEINTO VACATION"
+    S: "STARTTLS"
+    S: OK
+    C: Authenticate "DIGEST-MD5"
+    S: {128+}
+    S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
+       RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
+       cnNldD11dGYtOA==
+    C: {276+}
+    C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
+       QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
+       MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
+       ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
+       ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg="
+    S: {56+}
+    S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
+    C: ""
+    S: OK
+    
+    Another example demostrating use of SASL PLAIN mechanism under TLS:
 
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" ""
+<<Is this allowed?>>    
+    S: "SIEVE" "FILEINTO VACATION"
+    S: "STARTTLS"
+    S: OK
+    C: STARTTLS
+    S: OK
+    <TLS negotiation, further commands are under TLS layer>
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" "PLAIN"
+    S: "SIEVE" "FILEINTO VACATION"
+    S: OK
     C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
+    S: NO
+    C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
+    S: NO
+    C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
     S: BYE "Too many failed authentication attempts"
-    Server closes connection
-
+    <Server closes connection>
 
 
 2.2.  STARTTLS Command
 
-    The STARTTLS command requests to commencement of a TLS negotiation.
+    Support for STARTTLS command in servers is optional. Its availability
+    is advertised with "STARTTLS" capability as described in section
+    1.8.
+
+    The STARTTLS command requests commencement of a TLS negotiation.
     The negotiation begins immediately after the CRLF in the OK
     response. After a client issues a STARTTLS command, it MUST NOT
     issue further commands until a server response is seen and the TLS
     negotiation is complete.
 
-     The STARTTLS command is only valid in non-authenticated state. The
+    The STARTTLS command is only valid in non-authenticated state. The
     server remains in non-authenticated state, even if client
     credentials are supplied during the TLS negotiation. The SASL [SASL]
-    EXTERNAL mechanism MAY be used to authenticate once TLS clie nt
+    EXTERNAL mechanism MAY be used to authenticate once TLS client
     credentials are successfully exchanged, but servers supporting the
     STARTTLS command are not required to support the EXTERNAL mechanism.
 
     After the TLS layer is established, the server MUST re-issue the
-    capability results. This is necessary to protect against man-in-the-
-    middle attacks which alter the capabilities list prior to STARTTLS.
+    capability results, followed by an OK response. This is necessary to
+    protect against man-in-the-middle attacks which alter the capabilities
+    list prior to STARTTLS.
+    
+    The capability result MUST NOT include the STARTTLS capability.
+    
     The client MUST discard cached capability information and replace it
     with the new information. The server MAY advertise different
     capabilities after STARTTLS.
@@ -598,7 +590,10 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     C: STARTTLS
     S: OK
     <TLS negotiation, further commands are under TLS layer>
-
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
+    S: "SIEVE" "FILEINTO VACATION"
+    S: OK
 
 
 2.3.  LOGOUT Command
@@ -615,12 +610,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     <connection terminated>
 
 
-
-Expires January 21, 2003        Martin                         [Page 10]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
 2.4.  CAPABILITY Command
 
     The CAPABILITY command requests the server capabilities as described
@@ -632,6 +621,7 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     Example:
 
+    C: CAPABILITY
     S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
     S: "SASL" "PLAIN KERBEROS_V4 GSSAPI"
     S: "SIEVE" "FILEINTO VACATION"
@@ -639,8 +629,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     S: OK
 
 
-
-
 2.5.  HAVESPACE Command
 
     Arguments:
@@ -657,26 +645,16 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     Example:
 
     C: HAVESPACE "myscript" 999999
-    S: NO "Quota exceeded"
+    S: NO (QUOTA) "Quota exceeded"
 
     C: HAVESPACE "foobar" 435
     S: OK
 
 
-
-
 2.6.  PUTSCRIPT Command
 
     Arguments:
          String - Script name
-
-
-
-Expires January 21, 2003        Martin                         [Page 11]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
          String - Script content
 
     The PUTSCRIPT command is used by the client to submit a Sieve script
@@ -722,17 +700,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     S: OK
 
 
-
-
-
-
-
-
-Expires January 21, 2003        Martin                         [Page 12]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
 2.7.  LISTSCRIPTS Command
 
     This command lists the scripts the user has on the server. Upon
@@ -750,15 +717,16 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     S: OK
 
 
-
 2.8.  SETACTIVE Command
 
     Arguments:
          String - script name
 
     This command sets a script active. If the script name is the empty
-    string (i.e. "") then any active script is disabled. If the script
-    does not exist on the server then the server MUST reply with a NO
+    string (i.e. "") then any active script is disabled. Disabling an active script
+    when there is no script active is not an error and MUST result in OK reply.
+
+    If the script does not exist on the server then the server MUST reply with a NO
     response.
 
     Examples:
@@ -773,7 +741,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     S: No "There is no script by that name"
 
 
-
 2.9.  GETSCRIPT Command
 
     Arguments:
@@ -781,14 +748,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     This command gets the contents of the specified script. If the
     script does not exist the server MUST reply with a NO response. Upon
-
-
-
-Expires January 21, 2003        Martin                         [Page 13]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
     success a string with the contents of the script is returned
     followed by a OK response.
 
@@ -802,8 +761,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     S: OK
 
 
-
-
 2.10.  DELETESCRIPT Command
 
     Parameters:
@@ -825,48 +782,61 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     S: No "You may not delete an active script"
 
 
-
 3.  Sieve URL Scheme
 
-    URL scheme name: "sieve"
+    URI scheme name: sieve
+    
+    Status: permanent
 
-    URL scheme syntax:
+    URI scheme syntax:
 
-      Described using ABNF [RFC 2234] and ABNF entities from RFC 2396.
+      Described using ABNF [ABNF] and ABNF entities from [URI-GEN].
 
-      sieveurl = "sieve://" [ hostport ] "/" scriptname
+      sieveurl = sieveurl-server / sieveurl-script
+      
+      sieveurl-server = "sieve://" authority
+      
+      sieveurl-script = "sieve://" [ authority ] "/" scriptname
 
       scriptname = *pchar
 
-
-
-Expires January 21, 2003        Martin                         [Page 14]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
-      Character encoding considerations: The script name, if present,
-      is in UTF-8.  Non-ASCII characters must be escaped as described
-      in RFC 2396.
-
-    Intended usage: A sieve URL identifies a sieve server or a sieve
-      script on a sieve server.  The latter always have the
-      application/sieve MIME type.
-
-    Applications and/or protocols which use this URL scheme name:
-      The protocol is described in this document.
+    URI scheme semantics:
+
+      A Sieve URL identifies a Sieve server or a Sieve
+      script on a Sieve server.  <<The latter form is associated with
+      application/sieve MIME type.>>
+      <<There is no MIME type associated with this URI.>>
+      
+      The server form is used in the REFERRAL response code in order
+      to designate another server where the client should perform
+      its operations. 
+      
+      The script form allows to retrieve (GETSCRIPT), update (PUTSCRIPT),
+      delete (DELETESCRIPT) or activate (SETACTIVE) the named script,
+      however the most typical action would be to retrieve the script.
+      If the script name is empty, the URI requests that the client
+      lists available scripts using LISTSCRIPTS command.
+
+    Encoding considerations: The script name, if present,
+      is in UTF-8.  Non-US-ASCII UTF-8 octets MUST be percent-encoded as
+      described in [URI-GEN].
+      
+      The user name (in the "authority" part), if present,
+      is in UTF-8.  Non-US-ASCII UTF-8 octets MUST be percent-encoded as
+      described in [URI-GEN].
+
+    Applications/protocols that use this URI scheme name:
+      <<The protocol is described in this document.>>
 
     Interoperability considerations:  None.
 
-    Security considerations:  None.
-
-    Relevant publications:  This document and RFC 3028.
+    Security considerations:  <<None>>.
 
-    Person & email address to contact for further information:
-      Author of this document.
+    Contact: Alexey Melnikov <alexey.melnikov@isode.com>
 
-    Author/Change controller:  Author of this document.
+    Author/Change controller: IESG.
 
+    References:  This document and <<RFC 3028>>.
 
 
 4.  Formal Syntax
@@ -893,14 +863,6 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
 
     UTF8-1                = %x80-BF
 
-
-
-
-Expires January 21, 2003        Martin                         [Page 15]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
     UTF8-2                = %xC0-DF UTF8-1
 
     UTF8-3                = %xE0-EF 2UTF8-1
@@ -916,12 +878,14 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     auth-type-name        = iana-token
                             ;; as defined in SASL [SASL]
 
-    command               = command-authenticate / command-logout / command-getscript /
-                            command-setactive / command-listscripts / command-deletescript /
-                            command-putscript / command-capability / command-havespace /
-                            command-starttls
+    command               = command-authenticate / command-logout /
+                            command-getscript / command-setactive /
+                            command-listscripts / command-deletescript /
+                            command-putscript / command-capability /
+                            command-havespace / command-starttls
 
-    command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]  *(CRLF string)
+    command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]
+                            *(CRLF string) CRLF
 
     command-capability    = "CAPABILITY" CRLF
 
@@ -942,22 +906,15 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     command-starttls      = "STARTTLS" CRLF
 
     literal               = "{" number  "+}" CRLF *OCTET
-                            ;; The number represents the number of octets
-                            ;; MUST be literal-utf8 except for values
+                            ;; The number represents the number of octets.
+                            ;; Sieve scripts MUST be sent as literal-utf8.
+                            ;; <<literal-utf8>> is defined in ACAP.
 
-    number                = *DIGIT
+    number                = 1*DIGIT
                             ;; A 32-bit unsigned number.
                             ;; (0 <= n < 4,294,967,296)
 
-
-
-
-Expires January 21, 2003        Martin                         [Page 16]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
-    quoted                = <"> *QUOTED-CHAR <">
+    quoted                = <"> *1024QUOTED-CHAR <">
                             ;; limited to 1024 octets between the <">s
 
     resp-code             = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" /
@@ -965,21 +922,46 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
                             "TRANSITION-NEEDED" / "TRYLATER" /
                             resp-code-ext
 
-    resp-code-referral   = "REFERRAL" SP sieveurl
+    resp-code-referral    = "REFERRAL" SP sieveurl
 
     resp-code-sasl        = "SASL" SP string
 
     resp-code-ext         = iana-token [SP extension-data]
                             ;; unknown codes MUST be tolerated by the client
 
-    response              = response-authenticate / response-logout / response-getscript /
-                            response-setactive / response-listscripts / response-deletescript /
-                            response-putscript / response-capability / response-havespace /
-                            response-starttls
+    response              = response-authenticate / response-logout /
+                            response-getscript / response-setactive /
+                            response-listscripts / response-deletescript /
+                            response-putscript / response-capability /
+                            response-havespace / response-starttls
 
     response-authenticate = *(string CRLF) (response-oknobye)
 
-    response-capability   = *(string [SP string] CRLF) response-oknobye
+    response-capability   = *(single-capability) response-oknobye
+     
+    single-capability     = capability-name [SP string] CRLF
+    
+    capability-name       = string
+     <<Note that literals are allowed!>>
+
+    initial-capabilities  = <"> "IMPLEMENTATION" <"> SP string /
+                            <"> "SASL" <"> SP sasl-mechs /
+                            <"> "SIEVE" <"> SP sieve-extensions /
+                            <"> "STARTTLS" <">
+                            ;; Each capability conforms to
+                            ;; the syntax for single-capability.
+                            ;; Also note that the capability name
+                            ;; can be returned as either literal
+                            ;; or quoted, even though only "quoted"
+                            ;; string is shown above.
+                            
+    sasl-mechs = string
+                 ; space separated list of SASL mechanisms,
+                 ; can be empty
+                 
+    sieve-extensions = string
+                 ; space separated list of supported SIEVE extensions,
+                 ; can be empty
 
     response-deletescript = response-oknobye
 
@@ -988,11 +970,12 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     response-havespace    = response-oknobye
 
     response-listscripts  = *(sieve-name [SP "ACTIVE"] CRLF) response-oknobye
-                   ;; ACTIVE may only occur with one sieve-name
+                            ;; ACTIVE may only occur with one sieve-name
 
     response-logout       = response-oknobye
 
-    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"] [SP string] CRLF
+    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"]
+                            [SP string] CRLF
 
     response-putscript    = response-oknobye
 
@@ -1005,17 +988,9 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     string                = quoted / literal
 
 
-
-
-
-Expires January 21, 2003        Martin                         [Page 17]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
 5.  Security Considerations
 
-    The AUTHENTICATE command uses SASL [SASL] and TLS [TLS] to provide
+    The AUTHENTICATE command uses SASL [SASL] and possibly TLS [TLS] to provide
     basic authentication, authorization, integrity and privacy services.
     When a SASL mechanism is used the security considerations for that
     mechanism apply.
@@ -1029,152 +1004,234 @@ Internet Draft           Managing Sieve Scripts            July 16, 2002
     encryption.
 
 
-6.  Acknowledgments
-
-    Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
-    Newman, Lyndon Nerenberg, Alexey Melnikov, Tim Showalter, Sarah
-    Robeson, and Walter Wong for help with this document.
-
-
-
-7.  Copyright
-
-    Copyright (C) The Internet Society 1999. All Rights Reserved.
-
-    This document and translations of it may be copied and furnished to
-    others, and derivative works that comment on or otherwise explain it
-    or assist in its implementation may be prepared, copied, published
-    and distributed, in whole or in part, without restriction of any
-    kind, provided that the above copyright notice and this paragraph
-    are included on all such copies and derivative works.  However, this
-    document itself may not be modified in any way, such as by removing
-    the copyright notice or references to the Internet Society or other
-    Internet organizations, except as needed for the purpose of
-    developing Internet standards in which case the procedures for
-    copyrights defined in the Internet Standards process must be
-    followed, or as required to translate it into languages other than
-    English.
-
-    The limited permissions granted above are perpetual and will not be
-    revoked by the Internet Society or its successors or assigns.
-
-    This document and the information contained herein is provided on an
-    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-
-
+6.  IANA Considerations
 
-Expires January 21, 2003        Martin                         [Page 18]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
+    IANA is requested to reserve TCP port number 2000 for use with
+    the Manage Sieve protocol described in this document.
 
+    IANA is requested to create a new registry for Manage Sieve
+    capabilities. The registration template for Manage Sieve capabilities
+    is specified in the next section.
+    Manage Sieve protocol capabilities MUST be specified in a standards
+    track or IESG approved experimental RFC.
+    
+    <<Add a new registry for response codes, as per ABNF comments.>>
+    
+    <<Reference to SIEVE URL registration.>>
+    
+    
+6.1. Manage Sieve Capability Registration Template
 
-    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+       To: iana@iana.org
+       Subject: Manage Sieve Capability Registration
 
-8.  References
+       Please register the following Manage Sieve Capability:
 
-     [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
-         Requirement Levels", RFC 2119, March 1997
+        Capability name: 
 
-         <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
+        Description: 
 
+        Relevant publications: 
 
-[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
-ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November
-1997.
+        Person & email address to contact for further information: 
+       
+        Author/Change controller: 
+               
 
-[ACAP] Newman, Myers, "ACAP -- Application Configuration Access Proto-
-col", RFC 2244, Innosoft, Netscape, November 1997.
+6.2. Registration of Initial Manage Sieve capabilities.
 
-[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
-4rev1", RFC 2060, October 1996.
+       To: iana@iana.org
+       Subject: Manage Sieve Capability Registration
 
-[IMAP-URL] Newman, C.; "IMAP URL Scheme"; RFC 2192; Innosoft; September,
-1997
+       Please register the following Manage Sieve Capability:
 
-[PLAIN] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
-Innosoft, June 1999.
+        Capability name: IMPLEMENTATION
 
-[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
-2222, Netscape Communications, October 1997.
+        Description: Its value contains name of server
+                     implementation and its version.
 
-[SASL-ANON] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November
-1997.
+        Relevant publications: this RFC, section 1.8.
 
-[SIEVE] Showalter, T.; "Sieve: A Mail Filtering Language"; RFC 3028;
-Mirapoint, Inc.; January 2001
+        Person & email address to contact for further information: 
+         Alexey Melnikov <alexey.melnikov@isode.com>
+       
+        Author/Change controller: IESG.
+        
 
-[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
-January 1999.
+       To: iana@iana.org
+       Subject: Manage Sieve Capability Registration
 
+       Please register the following Manage Sieve Capability:
 
-9.  Author's Address
+        Capability name: SASL
 
-    Tim Martin
-    Mirapoint Inc.
-    909 Hermosa Court
-    Sunnyvale, CA 94085
+        Description: Its value contains a space separated
+                     list of SASL mechanisms supported by server.
 
+        Relevant publications: this RFC, sections 1.8 and 2.1.
 
+        Person & email address to contact for further information: 
+         Alexey Melnikov <alexey.melnikov@isode.com>
+       
+        Author/Change controller: IESG.
+    
 
+       To: iana@iana.org
+       Subject: Manage Sieve Capability Registration
 
-Expires January 21, 2003        Martin                         [Page 19]
-
-Internet Draft           Managing Sieve Scripts            July 16, 2002
-
-
-    Phone: (408) 720-3835
-    EMail: tmartin@mirapoint.com
-
-
+       Please register the following Manage Sieve Capability:
 
+        Capability name: SIEVE
 
+        Description: Its value contains a space separated
+                     list of supported SIEVE extensions
 
+        Relevant publications: this RFC, section 1.8.
+         <<Also [SIEVE]>>
 
+        Person & email address to contact for further information: 
+         Alexey Melnikov <alexey.melnikov@isode.com>
+       
+        Author/Change controller: IESG.
 
 
+       To: iana@iana.org
+       Subject: Manage Sieve Capability Registration
 
+       Please register the following Manage Sieve Capability:
 
+        Capability name: STARTTLS
 
+        Description: This capability is returned if server
+                     supports TLS (STARTTLS command).
 
+        Relevant publications: this RFC, sections 1.8 and 2.2.
 
+        Person & email address to contact for further information: 
+         Alexey Melnikov <alexey.melnikov@isode.com>
+       
+        Author/Change controller: IESG.
+        
+    
+7.  References
 
+7.1.  Normative References
 
+    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
+        Requirement Levels", RFC 2119, March 1997
+        <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
 
+    [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+    Specifications: ABNF", RFC 4234, October 2005.
 
+    [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Proto-
+    col", RFC 2244, Innosoft, Netscape, November 1997.
 
+    [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security
+    Layer (SASL)", work in progress, draft-ietf-sasl-rfc2222bis-*.txt.
 
+    [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for user names
+    and passwords", work in progress, draft-ietf-sasl-saslprep-*.txt.
 
+    [StringPrep] Hoffman, P. and Blanchet, M., "Preparation of
+    Internationalized Strings ("stringprep")", work in progress,
+    draft-hoffman-rfc3454bis-*.txt.
 
+    [SASL-ANON] K. Zeilenga (Ed.), "The Anonymous SASL Mechanism",
+    work in progress, draft-ietf-sasl-anon-XX.txt (Obsoletes RFC 2245).
 
+    [SIEVE] Guenther, P. and Showalter, T., "Sieve: An Email Filtering
+    Language", work in Progress, draft-ietf-sieve-3028bis-XX.txt
 
+    [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
+    January 1999. <<Needs updating>>
 
+    [URI-GEN] Berners-Lee, T., Fielding, R. and L. Masinter,
+    "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986,
+    January 2005.
 
 
+7.2.  Informative References
 
+    [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
+    4rev1", RFC 3501, March 2003.
 
+    [PLAIN] K. Zeilenga, "The Plain SASL Mechanism",
+    work in progress, draft-ietf-sasl-plain-XX.txt (Updates RFC 2595).
 
 
+8.  Author's Address
 
+    Tim Martin
+    Mirapoint Inc.
+    909 Hermosa Court
+    Sunnyvale, CA 94085
+    Phone: (408) 720-3835
+    EMail: timmartin@alumni.cmu.edu
 
+    Alexey Melnikov
+    Isode Ltd.
+    5 Castle Business Village
+    36 Station Road
+    Hampton, Middlesex, TW12 2BX, GB
+    Email: alexey.melnikov@isode.com
 
 
+Intellectual Property Statement
 
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
 
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
 
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
 
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
 
 
+Disclaimer of Validity
 
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
 
+Copyright Statement
 
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
 
+Acknowledgment
 
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
 
 
+Appendix A. Acknowledgments
 
-Expires January 21, 2003        Martin                         [Page 20]
-
+    Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
+    Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, and Walter
+    Wong for help with this document.