draft-ietf-sieve-managesieve-03.txt   draft-ietf-sieve-managesieve-04.txt 
Sieve Working Group A. Melnikov, Ed. Sieve Working Group A. Melnikov, Ed.
Internet-Draft Isode Limited Internet-Draft Isode Limited
Intended status: Standards Track T. Martin Intended status: Standards Track T. Martin
Expires: June 4, 2009 BeThereBeSquare Inc. Expires: June 18, 2009 BeThereBeSquare Inc.
December 1, 2008 December 15, 2008
A Protocol for Remotely Managing Sieve Scripts A Protocol for Remotely Managing Sieve Scripts
draft-ietf-sieve-managesieve-03 draft-ietf-sieve-managesieve-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 4, 2009. This Internet-Draft will expire on June 18, 2009.
Abstract Abstract
Sieve scripts allow users to filter incoming email. Message stores Sieve scripts allow users to filter incoming email. Message stores
are commonly sealed servers so users cannot log into them, yet users are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them. This document must be able to update their scripts on them. This document
describes a protocol "ManageSieve" for securely managing Sieve describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server. This protocol allows a user to have scripts on a remote server. This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed multiple scripts, and also alerts a user to syntactically flawed
scripts. scripts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1.5. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Script Names . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Script Names . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8 1.7. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8
1.8. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 10 1.8. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 11 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 11
2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 16 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 16
2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 16 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 16
2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 17 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 17
2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 20 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 19
2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 20 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 20
2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 20 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 20
2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 21 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 21
2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 23 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 22
2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 23 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 23
2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 24 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 23
2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 24 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 24
2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 25 2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 24
2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 26 2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 25
2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 27 2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 26
2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 27 2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 27
2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 27 2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 27
3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 28 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 27
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 31 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . 37 5. Security Considerations . . . . . . . . . . . . . . . . . 36
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 37 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. ManageSieve Capability Registration Template . . . . . . . 38 6.1. ManageSieve Capability Registration Template . . . . . . . 37
6.2. Registration of Initial ManageSieve capabilities . . . . . 38 6.2. Registration of Initial ManageSieve capabilities . . . . . 37
6.3. ManageSieve Response Code Registration Template . . . . . 40 6.3. ManageSieve Response Code Registration Template . . . . . 39
6.4. Registration of Initial ManageSieve Response Codes . . . . 40 6.4. Registration of Initial ManageSieve Response Codes . . . . 39
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 46 7. Internationalization Considerations . . . . . . . . . . . 45
8. References . . . . . . . . . . . . . . . . . . . . . . . . 46 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 45
8.1. Normative References . . . . . . . . . . . . . . . . . . . 46
8.2. Informative References . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Normative References . . . . . . . . . . . . . . . . . . . 45
9.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . 49
1. Introduction 1. Introduction
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
skipping to change at page 4, line 29 skipping to change at page 4, line 29
This a line oriented protocol much like [IMAP] or [ACAP]. There are This a line oriented protocol much like [IMAP] or [ACAP]. There are
three data types: atoms, numbers and strings. Strings may be quoted three data types: atoms, numbers and strings. Strings may be quoted
or literal. See [ACAP] for detailed descriptions of these types. or literal. See [ACAP] for detailed descriptions of these types.
Each command consists of an atom (the command name) followed by zero Each command consists of an atom (the command name) followed by zero
or more strings and numbers terminated by CRLF. or more strings and numbers terminated by CRLF.
All client queries are replied to with either an OK, NO, or BYE All client queries are replied to with either an OK, NO, or BYE
response. Each response may be followed by a response code (see response. Each response may be followed by a response code (see
Section 1.3) and by a string consisting of human readable text in the Section 1.3) and by a string consisting of human readable text in the
local language, encoded in [UTF-8]. The contents of the string local language (as returned by the LANGUAGE capability, see
SHOULD be shown to the user and implementations MUST NOT attempt to Section 1.7), encoded in [UTF-8]. The contents of the string SHOULD
parse the message for meaning. be shown to the user and implementations MUST NOT attempt to parse
the message for meaning.
The BYE response SHOULD be used if the server wishes to close the The BYE response SHOULD be used if the server wishes to close the
connection. A server may wish to do this because the client was idle connection. A server may wish to do this because the client was idle
for too long or there were too many failed authentication attempts. for too long or there were too many failed authentication attempts.
This response can be issued at any time and should be immediately 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 an followed by a server hang-up of the connection. If a server has an
inactivity timeout resulting in client autologout it MUST be no less inactivity timeout resulting in client autologout it MUST be no less
than 30 minutes after successful authentication. The inactivity than 30 minutes after successful authentication. The inactivity
timeout MAY be less before authentication. timeout MAY be less before authentication.
skipping to change at page 9, line 5 skipping to change at page 9, line 7
SIEVE - List of space separated Sieve extensions (as listed in Sieve SIEVE - List of space separated Sieve extensions (as listed in Sieve
"require" action [SIEVE]) supported by the Sieve engine. This "require" action [SIEVE]) supported by the Sieve engine. This
capability MUST always be returned by the server. capability MUST always be returned by the server.
STARTTLS - If TLS [TLS] is supported by this implementation. Before STARTTLS - If TLS [TLS] is supported by this implementation. Before
advertising this capability a server MUST verify to the best of its advertising this capability a server MUST verify to the best of its
ability that TLS can be successfully negotiated by a client with ability that TLS can be successfully negotiated by a client with
common cipher suites. Specifically, a server should verify that a common cipher suites. Specifically, a server should verify that a
server certificate has been installed and that the TLS subsystem has server certificate has been installed and that the TLS subsystem has
successfully initialized. This capability SHOULD NOT be advertised successfully initialized. This capability SHOULD NOT be advertised
once STARTTLS or AUTHENTICATE command completes successfully. once STARTTLS or AUTHENTICATE command completes successfully. Client
and server implementations MUST implement the STARTTLS extension.
MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
actions a script can perform during a single evaluation. Note, that actions a script can perform during a single evaluation. Note, that
this is different from the total number of "redirect" actions a this is different from the total number of "redirect" actions a
script can contain. The value is a non-negative number represented script can contain. The value is a non-negative number represented
as a ManageSieve string. as a ManageSieve string.
NOTIFY - A space separated list of URI schema parts for supported NOTIFY - A space separated list of URI schema parts for supported
notification methods. This capability MUST be specified if the Sieve notification methods. This capability MUST be specified if the Sieve
implementation supports the "enotify" extension [NOTIFY]. implementation supports the "enotify" extension [NOTIFY].
skipping to change at page 13, line 47 skipping to change at page 13, line 47
To ensure interoperability, both client and server implementations of To ensure interoperability, both client and server implementations of
the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM] the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM]
SASL mechanism, as well as [PLAIN] over [TLS]. SASL mechanism, as well as [PLAIN] over [TLS].
Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in
other email related protocols, however a longer term goal is to other email related protocols, however a longer term goal is to
migrate email related protocols from using PLAIN over TLS to SCRAM- migrate email related protocols from using PLAIN over TLS to SCRAM-
HMAC-SHA-1 mechanism. HMAC-SHA-1 mechanism.
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 defined in the base ManageSieve protocol MUST give NO
responses, however ManageSieve extensions MAY allow other commands in
the ANONYMOUS Sieve script verification mode. Furthermore the
PUTSCRIPT command MUST NOT persistently 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 Examples (Note that long lines are folded for readability and are not
part of protocol exchange): part of protocol exchange):
S: "IMPLEMENTATION" "Example1 ManageSieved v001" S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI" S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation" S: "SIEVE" "fileinto vacation"
S: "STARTTLS" S: "STARTTLS"
S: "VERSION" "1.0" S: "VERSION" "1.0"
S: OK S: OK
C: Authenticate "DIGEST-MD5" C: Authenticate "DIGEST-MD5"
skipping to change at page 20, line 45 skipping to change at page 20, line 27
S: "STARTTLS" S: "STARTTLS"
S: OK S: OK
2.5. HAVESPACE Command 2.5. HAVESPACE Command
Arguments: String - name Arguments: String - name
Number - script size Number - script size
The HAVESPACE command is used to query the server for available The HAVESPACE command is used to query the server for available
space. Clients specify the name they wish to save the script as and space. Clients specify the name they wish to save the script as and
its size in octets. Servers respond with an NO if storing a script its size in octets. Both parameters can be used by the server to see
with that name and size would fail or OK otherwise. Clients SHOULD if the script with the specified name and size is within user's
issue this command before attempting to place a script on the server. quota(s), for example the server MAY use the script name to check if
a script would be replaced or a new one would be created. Servers
respond with an NO if storing a script with that name and size would
fail or OK otherwise. Clients SHOULD issue this command before
attempting to place a script on the server.
Note that the OK response from the HAVESPACE command does not Note that the OK response from the HAVESPACE command does not
constitute a guarantee of success as server disk space conditions constitute a guarantee of success as server disk space conditions
could change between the client issuing the HAVESPACE and the client could change between the client issuing the HAVESPACE and the client
issuing the PUTSCRIPT commands. A QUOTA response code (see issuing the PUTSCRIPT commands. A QUOTA response code (see
Section 1.3) remains a possible (albeit unlikely) response to a Section 1.3) remains a possible (albeit unlikely) response to a
subsequent PUTSCRIPT with the same name and size. subsequent PUTSCRIPT with the same name and size.
Example: Example:
skipping to change at page 22, line 15 skipping to change at page 22, line 4
readable and SHOULD contain a specific error message giving the line readable and SHOULD contain a specific error message giving the line
number of the first error. Implementors should strive to produce number of the first error. Implementors should strive to produce
helpful error messages similar to those given by programming language helpful error messages similar to those given by programming language
compilers. Client implementations should note that this may be a compilers. Client implementations should note that this may be a
multiline literal string with more than one error message separated multiline literal string with more than one error message separated
by CRLFs. The human readable message is in the language returned in by CRLFs. The human readable message is in the language returned in
the latest LANGUAGE capability (or in "i-default", see Section 1.7), the latest LANGUAGE capability (or in "i-default", see Section 1.7),
encoded in UTF-8 [UTF-8]. encoded in UTF-8 [UTF-8].
An OK response MAY contain the WARNINGS response code. In such case An OK response MAY contain the WARNINGS response code. In such case
the message that follows the OK response SHOULD contain a specific the human readable message that follows the OK response SHOULD
warning message (or messages) giving the line number(s) in the script contain a specific warning message (or messages) giving the line
that might contain errors not intended by the script writer. A number(s) in the script that might contain errors not intended by the
client seeing such response code SHOULD present the message to the script writer. The human readable message is in the language
user. returned in the latest LANGUAGE capability (or in "i-default", see
Section 1.7), encoded in UTF-8 [UTF-8] A client seeing such response
code SHOULD present the message to the user.
Examples: Examples:
C: Putscript "foo" {31+} C: Putscript "foo" {31+}
C: #comment C: #comment
C: InvalidSieveCommand C: InvalidSieveCommand
C: C:
S: NO "line 2: Syntax error" S: NO "line 2: Syntax error"
C: Putscript "mysievescript" {110+} C: Putscript "mysievescript" {110+}
skipping to change at page 26, line 43 skipping to change at page 26, line 27
C: CheckScript {31+} C: CheckScript {31+}
C: #comment C: #comment
C: InvalidSieveCommand C: InvalidSieveCommand
C: C:
S: NO "line 2: Syntax error" S: NO "line 2: Syntax error"
A ManageSieve server supporting this command MUST NOT check if the A ManageSieve server supporting this command MUST NOT check if the
script will put the current user over its quota limit. script will put the current user over its quota limit.
An OK response MAY contain the WARNINGS response code. In such case An OK response MAY contain the WARNINGS response code. In such case
the message that follows the OK response SHOULD contain a specific the human readable message that follows the OK response SHOULD
warning message (or messages) giving the line number(s) in the script contain a specific warning message (or messages) giving the line
that might contain errors not intended by the script writer. A number(s) in the script that might contain errors not intended by the
client seeing such response code SHOULD present the message to the script writer. The human readable message is in the language
user. returned in the latest LANGUAGE capability (or in "i-default", see
Section 1.7), encoded in UTF-8 [UTF-8] A client seeing such response
The CHECKSCRIPT command is available in the ANONYMOUS Sieve script code SHOULD present the message to the user.
verification mode.
2.13. NOOP Command 2.13. NOOP Command
Arguments: String - tag to echo back (optional) Arguments: String - tag to echo back (optional)
The NOOP command does nothing, beyond returning a response to the The NOOP command does nothing, beyond returning a response to the
client. It may be used by clients for protocol re-synchronisation or client. It may be used by clients for protocol re-synchronisation or
to reset any inactivity auto-logout timer on the server. to reset any inactivity auto-logout timer on the server.
The NOOP command is available in the ANONYMOUS Sieve script
verification mode.
The response to the NOOP command is always OK, followed by the TAG The response to the NOOP command is always OK, followed by the TAG
response code together with the supplied string; if no string was response code together with the supplied string; if no string was
supplied in the NOOP command, the TAG response code MUST NOT be supplied in the NOOP command, the TAG response code MUST NOT be
included. included.
Examples: Examples:
C: NOOP C: NOOP
S: OK "NOOP completed" S: OK "NOOP completed"
skipping to change at page 31, line 47 skipping to change at page 30, line 47
SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
;; <UTF8-2>, <UTF8-3> and <UTF8-4> ;; <UTF8-2>, <UTF8-3> and <UTF8-4>
;; are defined in [UTF-8] ;; are defined in [UTF-8]
ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
;; Any CHAR except ATOM-SPECIALS ;; Any CHAR except ATOM-SPECIALS
ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL /
QUOTED-SPECIALS QUOTED-SPECIALS
QUOTED-SPECIALS = <"> / "\"
atom = 1*1024ATOM-CHAR atom = 1*1024ATOM-CHAR
iana-token = atom iana-token = atom
;; MUST be registered with IANA ;; MUST be registered with IANA
auth-type = DQUOTE auth-type-name DQUOTE auth-type = DQUOTE auth-type-name DQUOTE
auth-type-name = iana-token auth-type-name = iana-token
;; as defined in SASL [SASL] ;; as defined in SASL [SASL]
command = (command-any / command-auth / command = (command-any / command-auth /
command-nonauth) CRLF command-nonauth) CRLF
;; Modal based on state ;; Modal based on state
command-any = command-capability / command-logout / command-any = command-capability / command-logout /
skipping to change at page 33, line 4 skipping to change at page 31, line 49
command-listscripts = "LISTSCRIPTS" command-listscripts = "LISTSCRIPTS"
command-noop = "NOOP" [SP string] command-noop = "NOOP" [SP string]
command-logout = "LOGOUT" command-logout = "LOGOUT"
command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
command-checkscript = "CHECKSCRIPT" SP sieve-script command-checkscript = "CHECKSCRIPT" SP sieve-script
sieve-script = string
sieve-script = string
command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
new-sieve-name new-sieve-name
old-sieve-name = sieve-name old-sieve-name = sieve-name
new-sieve-name = sieve-name new-sieve-name = sieve-name
command-setactive = "SETACTIVE" SP active-sieve-name command-setactive = "SETACTIVE" SP active-sieve-name
command-starttls = "STARTTLS" command-starttls = "STARTTLS"
skipping to change at page 35, line 4 skipping to change at page 33, line 50
response-unauthenticate response-unauthenticate
response-authenticate = *(string CRLF) response-authenticate = *(string CRLF)
((response-ok [response-capability]) / ((response-ok [response-capability]) /
response-nobye) response-nobye)
;; <response-capability> is REQUIRED if a ;; <response-capability> is REQUIRED if a
;; SASL security layer was negotiated and ;; SASL security layer was negotiated and
;; MUST be omitted otherwise. ;; MUST be omitted otherwise.
response-capability = *(single-capability) response-oknobye response-capability = *(single-capability) response-oknobye
single-capability = capability-name [SP string] CRLF
single-capability = capability-name [SP string] CRLF
capability-name = string capability-name = string
;; Note that literal-s2c is allowed. ;; Note that literal-s2c is allowed.
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
DQUOTE "SASL" DQUOTE SP sasl-mechs / DQUOTE "SASL" DQUOTE SP sasl-mechs /
DQUOTE "SIEVE" DQUOTE SP sieve-extensions / DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str / DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
DQUOTE "NOTIFY" DQUOTE SP notify-mechs / DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
DQUOTE "STARTTLS" DQUOTE / DQUOTE "STARTTLS" DQUOTE /
DQUOTE "LANGUAGE" DQUOTE SP language / DQUOTE "LANGUAGE" DQUOTE SP language /
skipping to change at page 46, line 9 skipping to change at page 45, line 9
Purpose: This response code name is followed by a string specified Purpose: This response code name is followed by a string specified
in the command that caused this response. It is typically used in the command that caused this response. It is typically used
for client state synchronization. for client state synchronization.
Published Specification(s): [RFCXXXX] Published Specification(s): [RFCXXXX]
Person & email address to contact for further information: Alexey Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com> Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG. Author/Change controller: IESG.
7. Acknowledgements 7. Internationalization Considerations
The LANGUAGE capability (see Section 1.7) allows a client to discover
the current language used in all human readable responses that might
be returned at the end of any OK/NO/BYE response. Human readable
text in OK responses typically doesn't need to be shown to the user,
unless it is returned in response to PUTSCRIPT or CHECKSCRIPT command
that also contain the WARNING response code Section 1.3. Human
readable text from NO/BYE responses SHOULD be shown to the user,
unless the client can automatically handle failure of the command
that caused such response. Clients SHOULD use response codes
(Section 1.3) for automatic error handling. Response codes can also
be used by the client to present error messages in a language
understood by the user, for example if the LANGUAGE capability
doesn't return a language understood by the user.
8. Acknowledgements
Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick
Ben Koetter, Bjoern Hoehrmann and Martin Duerst for help with this Ben Koetter, Bjoern Hoehrmann and Martin Duerst for help with this
document. Special thank you to Phil Pennock for providing text for document. Special thank you to Phil Pennock for providing text for
the NOOP command, as well as finding various bugs in the document. the NOOP command, as well as finding various bugs in the document.
8. References 9. References
8.1. Normative References 9.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
skipping to change at page 47, line 27 skipping to change at page 46, line 44
June 2006. June 2006.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006. Languages", RFC 4646, September 2006.
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[SASL-ANON]
Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[SASLprep] [SASLprep]
Zeilenga, K., "SASLprep: Stringprep Profile for User Names Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005. and Passwords", RFC 4013, February 2005.
[SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge [SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge
Response Authentication Mechanism (SCRAM)", Response Authentication Mechanism (SCRAM)",
draft-newman-auth-scram-07.txt (work in progress), draft-newman-auth-scram-07.txt (work in progress),
November 2008. November 2008.
[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
skipping to change at page 48, line 19 skipping to change at page 47, line 33
[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[X509-SRV] [X509-SRV]
Santesson, S., "Internet X.509 Public Key Infrastructure Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name", Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007. RFC 4985, August 2007.
8.2. Informative References 9.2. Informative References
[DIGEST-MD5] [DIGEST-MD5]
Leach, P. and C. Newman, "Using Digest Authentication as a Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000. SASL Mechanism", RFC 2831, May 2000.
[I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
draft-freed-sieve-ihave-03.txt (work in progress), draft-freed-sieve-ihave-03.txt (work in progress),
October 2008. October 2008.
[IANA-GUIDELINES] [IANA-GUIDELINES]
 End of changes. 31 change blocks. 
70 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/