draft-ietf-lemonade-imap-notify-03.txt   draft-ietf-lemonade-imap-notify-04.txt 
Network Working Group Curtis King Network Working Group Curtis King
Internet-Draft Alexey Melnikov Internet-Draft Alexey Melnikov
Intended Status: Proposed Standard Isode Ltd. Intended Status: Proposed Standard Isode Ltd.
Arnt Gulbrandsen Arnt Gulbrandsen
Oryx Mail Systems GmbH Oryx Mail Systems GmbH
February 8, 2008 February 25, 2008
The IMAP NOTIFY Extension The IMAP NOTIFY Extension
draft-ietf-lemonade-imap-notify-03.txt draft-ietf-lemonade-imap-notify-04.txt
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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. The list of Internet- http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft expires in July 2008. This Internet-Draft expires in July 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines an IMAP extension which allows a client to This document defines an IMAP extension which allows a client to
request specific kinds of unsolicited notifications for specified request specific kinds of unsolicited notifications for specified
mailboxes, such as messages being added to or deleted from mailboxes, such as messages being added to or deleted from mailboxes.
mailboxes.
Internet-draft February 2008 Internet-draft February 2008
[[Add Updates: RFC-CONTEXT to the headers]] [[Add Updates: RFC-CONTEXT to the headers]]
1. Conventions Used in This Document 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
Formal syntax is defined by [RFC4234] as extended by [RFC3501] and Formal syntax is defined by [RFC5234] as extended by [RFC3501] and
[RFC4466]. [RFC4466].
The acronym MSN stands for Message Sequence Numbers (see Section The acronym MSN stands for Message Sequence Numbers (see Section
2.3.1.2 of [RFC3501]). 2.3.1.2 of [RFC3501]).
Example lines prefaced by "C:" are sent by the client and ones Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. "[...]" means elision. prefaced by "S:" by the server. "[...]" means elision.
2. Overview and rationale 2. Overview and rationale
The IDLE command (defined in [RFC2177]) provides a way for the The IDLE command (defined in [RFC2177]) provides a way for the client
client to go into a mode where the IMAP server pushes notifications to go into a mode where the IMAP server pushes notifications about
about IMAP mailstore events for the selected mailbox. However, the IMAP mailstore events for the selected mailbox. However, the IDLE
IDLE extension doesn't restrict or control which server events can extension doesn't restrict or control which server events can be
be sent, or what information the server sends in response to each sent, or what information the server sends in response to each event.
event. Also, IDLE only applies to the selected mailbox, thus Also, IDLE only applies to the selected mailbox, thus requiring an
requiring an additional TCP connection per mailbox. additional TCP connection per mailbox.
This document defines an IMAP extension that allows clients to This document defines an IMAP extension that allows clients to
express their preferences about unsolicited events generated by the express their preferences about unsolicited events generated by the
server. The extension allows clients to only receive events they server. The extension allows clients to only receive events they are
are interested in, while servers know that they don't need to go interested in, while servers know that they don't need to go into
into effort of generating certain types of untagged responses. effort of generating certain types of untagged responses.
Without the NOTIFY command defined in this document, and IMAP server Without the NOTIFY command defined in this document, and IMAP server
will only send information about mailstore changes to the client in will only send information about mailstore changes to the client in
the following cases: the following cases:
- as the result of a client command (e.g. FETCH responses to - as the result of a client command (e.g. FETCH responses to
a FETCH or STORE command), a FETCH or STORE command),
- unsolicited responses sent just before the end of a command - unsolicited responses sent just before the end of a command
(e.g. EXISTS or EXPUNGE) as the result of changes in other (e.g. EXISTS or EXPUNGE) as the result of changes in other
sessions, and sessions, and
- during an IDLE command. - during an IDLE command.
The NOTIFY command extends what information may be returned in those The NOTIFY command extends what information may be returned in those
last two cases, and also permits and requires the server to send last two cases, and also permits and requires the server to send
information about updates between command. The NOTIFY command also information about updates between command. The NOTIFY command also
Internet-draft February 2008 Internet-draft February 2008
allows for the client to extend what information is sent unsolicited allows for the client to extend what information is sent unsolicited
about the selected mailbox, and to request some update information about the selected mailbox, and to request some update information to
to be sent regarding other mailboxes. be sent regarding other mailboxes.
For the new messages delivered to or appended to the selected For the new messages delivered to or appended to the selected
mailbox, the NOTIFY command can be used to request that a set of mailbox, the NOTIFY command can be used to request that a set of
attributes be sent to the client in an unsolicited FETCH response. attributes be sent to the client in an unsolicited FETCH response.
This allows a client to be passive recipient of events and new mail, This allows a client to be passive recipient of events and new mail,
and be able to maintain full synchronisation without having to issue and be able to maintain full synchronisation without having to issue
any subsequent commands except to modify the state of the mailbox on any subsequent commands except to modify the state of the mailbox on
the server. the server.
Some mobile clients, however, may want mail "pushed" only for mail Some mobile clients, however, may want mail "pushed" only for mail
that matches a SEARCH pattern. To meet that need [CONTEXT] is that matches a SEARCH pattern. To meet that need [CONTEXT] is
augmented by this document to extend the UPDATE return option to augmented by this document to extend the UPDATE return option to
specify a list of fetch-atts to be returned when a new message is specify a list of fetch-atts to be returned when a new message is
delivered or appended in another session. delivered or appended in another session.
[[Should the following be a normative subsection?]] IMAP servers [[Should the following be a normative subsection?]] IMAP servers
which support this extension advertise the X-DRAFT-W03-NOTIFY which support this extension advertise the X-DRAFT-W04-NOTIFY
extension. extension.
A server implementing this extension is not required to implement A server implementing this extension is not required to implement
LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must
be able to return extended LIST responses defined in [LISTEXT]. be able to return extended LIST responses defined in [LISTEXT].
[[RFC-Editor: Please delete the following before publication: [[RFC-Editor: Please delete the following before publication:
Comments regarding this draft may be sent either to the Comments regarding this draft may be sent either to the
lemonade@ietf.org mailing list or to the authors.]] lemonade@ietf.org mailing list or to the authors.]]
3. The NOTIFY Command 3. The NOTIFY Command
Arguments: "ADD" or "SET" Arguments: "SET"
optional STATUS indicator optional STATUS indicator
Mailboxes to be watched Mailboxes to be watched
Events about which to notify the client Events about which to notify the client
Or Or
Arguments: "NONE" Arguments: "NONE"
Responses: Possibly untagged STATUS responses (for ADD/SET) Responses: Possibly untagged STATUS responses (for SET)
Result: OK - The server will notify the client as requested. Result: OK - The server will notify the client as requested.
NO - Unsupported notify event, NOTIFY too complex or NO - Unsupported notify event, NOTIFY too complex or
expensive, etc. expensive, etc.
BAD - Command unknown, invalid, unsupported or unknown BAD - Command unknown, invalid, unsupported or unknown
Internet-draft February 2008 Internet-draft February 2008
arguments. arguments.
The NOTIFY command informs the server that the client listens for The NOTIFY command informs the server that the client listens for
event notifications all the time (even when no command is in event notifications all the time (even when no command is in
progress) and requests the server to notify it about the specified progress) and requests the server to notify it about the specified
set of events. The NOTIFY command has 3 forms. The NOTIFY NONE set of events. The NOTIFY command has two forms. NOTIFY NONE
specifies that the client is not interested in any kind of event specifies that the client is not interested in any kind of event
happening on the server. The NOTIFY ADD prepends one or more events happening on the server. NOTIFY SET replaces the current list of
to the list of events which are interesting to the client. The interesting events with a new list of events.
NOTIFY SET replaces the current list of interesting events with a
new list of events. (Note that NOTIFY SET <events> is effectively
the same as NOTIFY NONE followed by NOTIFY ADD <events>.)
Until the NOTIFY command is used for the first time, the server only Until the NOTIFY command is used for the first time, the server only
sends notifications while a command is being processed, and notifies sends notifications while a command is being processed, and notifies
the client about these events on the selected mailbox: (see section the client about these events on the selected mailbox: (see section 5
5 for definitions): MessageNew, MessageExpunge, FlagChange. It does for definitions): MessageNew, MessageExpunge, FlagChange. It does not
not notify the client about any events on other mailboxes. notify the client about any events on other mailboxes.
The effect of a successful NOTIFY command lasts until the next The effect of a successful NOTIFY command lasts until the next NOTIFY
NOTIFY command, or until the IMAP connection is closed. command, or until the IMAP connection is closed.
A successful NOTIFY ADD/SET command MUST cause the server to A successful NOTIFY SET command MUST cause the server to immediately
immediately return any accumulated changes to the mailbox (if any), return any accumulated changes to the mailbox (if any), such as flag
such as flag changes, new or expunged messages. This is equivalent changes, new or expunged messages. This is equivalent to NOOP command
to NOOP command being issued by the client just before the NOTIFY being issued by the client just before the NOTIFY SET command.
ADD/SET command.
If the NOTIFY command enables MessageNew, MessageExpunge, If the NOTIFY command enables MessageNew, MessageExpunge,
AnnotationChange or FlagChange notification for a mailbox, and the AnnotationChange or FlagChange notification for a mailbox, and the
client has specified the STATUS indicator parameter, then the server client has specified the STATUS indicator parameter, then the server
MUST send a STATUS response for that mailbox before NOTIFY's tagged MUST send a STATUS response for that mailbox before NOTIFY's tagged
OK. If MessageNew is enabled, the STATUS response MUST contain OK. If MessageNew is enabled, the STATUS response MUST contain
MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the
STATUS response MUST contain MESSAGES. If either AnnotationChange or STATUS response MUST contain MESSAGES. If either AnnotationChange or
FlagChange are included, the STATUS response MUST contain FlagChange are included, the STATUS response MUST contain UIDVALIDITY
UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows
parameter allows the client to avoid the additional STATUS the client to avoid the additional STATUS responses. This might be
responses. This might be useful if the client has already retrieved useful if the client has already retrieved this information before
this information before issuing the NOTIFY command. issuing the NOTIFY command.
Clients are advised to limit the number of mailboxes used with Clients are advised to limit the number of mailboxes used with
NOTIFY. Particularly, if a client asks for events for all accessible NOTIFY. Particularly, if a client asks for events for all accessible
mailboxes, the server may swamp the client with updates about shared mailboxes, the server may swamp the client with updates about shared
mailboxes. This wastes both server and network resources. For mailboxes. This wastes both server and network resources. For
each mailbox specified, the server verifies that the client has each mailbox specified, the server verifies that the client has
access using the following test: access using the following test:
Internet-draft February 2008
- If the name does not refer to an existing mailbox, the server MUST - If the name does not refer to an existing mailbox, the server MUST
ignore it. ignore it.
- If the name refers to a mailbox which the client can't LIST, the - If the name refers to a mailbox which the client can't LIST, the
Internet-draft February 2008
server MUST ignore it. For a server that implements [RFC4314] this server MUST ignore it. For a server that implements [RFC4314] this
means that if the client that doesn't have the 'l' (lookup) right means that if the client that doesn't have the 'l' (lookup) right
for the name, then the server MUST ignore the mailbox. This for the name, then the server MUST ignore the mailbox. This
behavior prevents dislosure on potentially confidential behavior prevents dislosure on potentially confidential information
information to clients which don't have rights to know it. to clients which don't have rights to know it.
- If the name refers to a mailbox which the client can LIST (e.g. it - If the name refers to a mailbox which the client can LIST (e.g. it
has the 'l' right from [RFC4314]), but misses another right has the 'l' right from [RFC4314]), but misses another right
required for processing of the specified event(s), then the server required for processing of the specified event(s), then the server
MUST respond with an untagged extended LIST response containing MUST respond with an untagged extended LIST response containing the
the \NoAccess name attribute. [[Alexey: Note, the newly defined \NoAccess name attribute. [[Alexey: Note, the newly defined
\NoAccess doesn't mean that the client doesn't have any rights \NoAccess doesn't mean that the client doesn't have any rights
other than 'l'. The \NoAccess is only meaningful in the context of other than 'l'. The \NoAccess is only meaningful in the context of
the specified NOTIFY command.]] the specified NOTIFY command.]]
The server SHOULD return the tagged OK response if the client has The server SHOULD return the tagged OK response if the client has
access to at least one of the mailboxes specified in the current access to at least one of the mailboxes specified in the current list
list of interesting events. The server MAY return the tagged NO of interesting events. The server MAY return the tagged NO response
response if the client has no access to any of the specified if the client has no access to any of the specified mailboxes and no
mailboxes and no access can ever be granted in the future (e.g. the access can ever be granted in the future (e.g. the client specified
client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't exist and LIST
exist and LIST returns \Noinferiors for the parent 'Bar'). returns \Noinferiors for the parent 'Bar').
If the notification would be prohibitively expensive for the server If the notification would be prohibitively expensive for the server
(e.g. "notify me of all flag changes in all mailboxes"), the server (e.g. "notify me of all flag changes in all mailboxes"), the server
MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW]
response. response.
If the client requests information for events of an unsupported If the client requests information for events of an unsupported type,
type, the server MUST refuse the command with a tagged NO response the server MUST refuse the command with a tagged NO response (not a
(not a BAD). This response SHOULD contain the BADEVENT response BAD). This response SHOULD contain the BADEVENT response code, which
code, which MUST list names of all events supported by the server. MUST list names of all events supported by the server.
Here's an example: Here's an example:
S: * OK [CAPABILITY IMAP4REV1 NOTIFY] S: * OK [CAPABILITY IMAP4REV1 NOTIFY]
C: a login bob alice C: a login bob alice
S: a OK Password matched S: a OK Password matched
C: b notify set status (selected MessageNew (uid C: b notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge) body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (subtree Lists MessageNew)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES
500) 500)
S: [...] S: [...]
Internet-draft February 2008
S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0)
S: b OK done S: b OK done
C: c select inbox C: c select inbox
S: [...] (the usual 7-8 responses to SELECT) S: [...] (the usual 7-8 responses to SELECT)
Internet-draft February 2008
S: c OK INBOX selected S: c OK INBOX selected
(Time passes. A new message is delivered to mailbox (Time passes. A new message is delivered to mailbox
Lists/Lemonade.) Lists/Lemonade.)
S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES
MESSAGES 501) 501)
(Time passes. A new message is delivered to inbox.) (Time passes. A new message is delivered to inbox.)
S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)]
Subject)] {75} {75}
S: Subject: Re: good morning S: Subject: Re: good morning
S: From: alice@example.org S: From: alice@example.org
S: To: bob@example.org S: To: bob@example.org
S: S:
S: ) S: )
(Time passes. The client decides it wants to know about (Time passes. The client decides it wants to know about
one more mailbox.) one more mailbox.)
C: d notify add status (mailboxes misc MessageNew) C: d notify set status (selected MessageNew (uid
body.peek[header.fields (from to subject)]) MessageExpunge)
(subtree Lists MessageNew) (mailboxes misc MessageNew)
S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999)
(This command enables notification on one mailbox and (This command enables notification on one mailbox and
otherwise changes nothing, so one STATUS response is otherwise changes nothing, so one STATUS response is
sent.) sent.[[AM: This is no longer correct.]])
S: d OK done S: d OK done
4. Interaction with the IDLE Command 4. Interaction with the IDLE Command
If IDLE (as well as this extension) is supported, while processing If IDLE (as well as this extension) is supported, while processing
IDLE the server MUST send the same events as instructed by the IDLE the server MUST send the same events as instructed by the client
client using the NOTIFY command. using the NOTIFY command.
NOTIFY makes IDLE unnecessary for some clients. If a client does not NOTIFY makes IDLE unnecessary for some clients. If a client does not
use MSNs and '*' in commands, it can request MessageExpunge and use MSNs and '*' in commands, it can request MessageExpunge and
MessageNew for the selected mailbox using the NOTIFY command instead MessageNew for the selected mailbox using the NOTIFY command instead
of entering the IDLE mode. of entering IDLE mode.
5. Event Types 5. Event Types
Only some of the events in [MSGEVENT] can be expressed in IMAP, and Only some of the events in [MSGEVENT] can be expressed in IMAP, and
for some of them there are several possible ways to express the for some of them there are several possible ways to express the
event. event.
This section specifies the events which an IMAP server can notify an This section specifies the events which an IMAP server can notify an
IMAP client, and how. IMAP client, and how.
The server SHOULD omit notifying the client if the event is caused by
this client. For example, if the client issues CREATE and has
Internet-draft February 2008 Internet-draft February 2008
The server SHOULD omit notifying the client if the event is caused
by this client. For example, if the client issues CREATE and has
requested MailboxName event that would cover the newly created requested MailboxName event that would cover the newly created
mailbox, the server SHOULD NOT notify the client of the MailboxName mailbox, the server SHOULD NOT notify the client of the MailboxName
change. change.
All event types described in this document require the 'l' and 'r' All event types described in this document require the 'l' and 'r'
rights (see [RFC4314]) on all observed mailboxes. Servers that rights (see [RFC4314]) on all observed mailboxes. Servers that don't
don't implement [RFC4314] should map the above rights to their implement [RFC4314] should map the above rights to their access
access control model. control model.
If the client instructs the server not to send MessageNew or Note that MessageNew and MessageExpunge must be specified together.
It is not possible to specify one, but not the other.
If the client instructs the server not to send MessageNew and
MessageExpunge for the selected mailbox, the server MUST still send MessageExpunge for the selected mailbox, the server MUST still send
EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501]
section 7). In other words, MessageExpunge instructs the server to section 7). In other words, MessageExpunge instructs the server to
notify the client immediately, and the lack of MessageExpunge notify the client immediately, and the lack of MessageExpunge
instructs the server to notify the client during execution of the instructs the server to notify the client during execution of the
next command as specified in [RFC3501]. MessageNew is handled next command as specified in [RFC3501]. MessageNew is handled
similarly by the server. similarly by the server.
5.1. FlagChange and AnnotationChange 5.1. FlagChange and AnnotationChange
skipping to change at page 7, line 41 skipping to change at page 7, line 42
response, which MUST include UID and FLAGS/ANNOTATION FETCH data response, which MUST include UID and FLAGS/ANNOTATION FETCH data
items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...]
responses. responses.
If a search context is in effect as specified in [CONTEXT], an If a search context is in effect as specified in [CONTEXT], an
ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if
appropriate. [[Alexey: I don't think this is needed: In this case, appropriate. [[Alexey: I don't think this is needed: In this case,
the FETCH response MUST precede the ESEARCH response.]] the FETCH response MUST precede the ESEARCH response.]]
If the change happens in another mailbox, then the response depends If the change happens in another mailbox, then the response depends
on whether CONDSTORE [RFC4551] is being used. If so, the server on whether CONDSTORE [RFC4551] is being used. If so, the server sends
sends a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox
UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the
STATUS response. If CONDSTORE is not used, the server does not STATUS response. If CONDSTORE is not used, the server does not
notify the client. notify the client.
FlagChange covers the MessageRead, MessageTrash, FlagsSet and FlagChange covers the MessageRead, MessageTrash, FlagsSet and
FlagsClear events in [MSGEVENT]. FlagsClear events in [MSGEVENT].
[[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent
for MessageRead. Arnt considers that unsound, since it involves for MessageRead. Arnt considers that unsound, since it involves
processing all messages in a mailbox after an event affecting only processing all messages in a mailbox after an event affecting only
one message, and since it's not reliable anyway.]]
Internet-draft February 2008 Internet-draft February 2008
one message, and since it's not reliable anyway.]]
Example in the selected mailbox: Example in the selected mailbox:
S: * 99 FETCH (UID 9999 FLAGS ($Junk)) S: * 99 FETCH (UID 9999 FLAGS ($Junk))
And in another, with CONDSTORE in use: And in another, with CONDSTORE in use:
S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665)
5.2. MessageNew 5.2. MessageNew
This covers both MessageNew and MessageAppend in [MSGEVENT]. This covers both MessageNew and MessageAppend in [MSGEVENT].
If the new/appended message is in the selected mailbox, the server If the new/appended message is in the selected mailbox, the server
notifies the client by sending an unsolicited EXISTS response, notifies the client by sending an unsolicited EXISTS response,
followed by an unsolicited FETCH response containing the information followed by an unsolicited FETCH response containing the information
requested by the client. A FETCH response SHOULD NOT be generated requested by the client. A FETCH response SHOULD NOT be generated for
for a new message created by the client on this particular a new message created by the client on this particular connection,
connection, for instance as the result of an APPEND or COPY command for instance as the result of an APPEND or COPY command to the
to the selected mailbox performed by the client itself. The server selected mailbox performed by the client itself. The server MAY also
MAY also send a RECENT response, if the server marks the message as send a RECENT response, if the server marks the message as \Recent.
\Recent.
Note that a single EXISTS response can be returned for multiple Note that a single EXISTS response can be returned for multiple
MessageAppend/MessageNew events. MessageAppend/MessageNew events.
If a search context is in effect as specified in [CONTEXT], an If a search context is in effect as specified in [CONTEXT], an
ESEARCH ADDTO will also be generated, if appropriate. In this case, ESEARCH ADDTO will also be generated, if appropriate. In this case,
the EXISTS response MUST precede the ESEARCH response. Both the the EXISTS response MUST precede the ESEARCH response. Both the
NOTIFY command and the SEARCH and SORT commands (see Section 7) can NOTIFY command and the SEARCH and SORT commands (see Section 7) can
specify attributes to be returned for new messages. These specify attributes to be returned for new messages. These attributes
attributes SHOULD be combined into a single FETCH response. The SHOULD be combined into a single FETCH response. The server SHOULD
server SHOULD avoid sending duplicate data. The FETCH response(s) avoid sending duplicate data. The FETCH response(s) MUST follow any
MUST follow any ESEARCH ADDTO responses. ESEARCH ADDTO responses.
If the new/appended message is in another mailbox, the server sends If the new/appended message is in another mailbox, the server sends
an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant
mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the
HIGHESTMODSEQ status data item MUST be included in the STATUS HIGHESTMODSEQ status data item MUST be included in the STATUS
response. response.
The client SHOULD NOT use FETCH attributes that implicitly set the The client SHOULD NOT use FETCH attributes that implicitly set the
\seen flag, or that presuppose the existence of a given bodypart. \seen flag, or that presuppose the existence of a given bodypart.
UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and
BODY/BODYSTRUCTURE may be the most useful attributes. BODY/BODYSTRUCTURE may be the most useful attributes.
Note that if a client asks to be notified of MessageNew events, the Note that if a client asks to be notified of MessageNew events, the
number of messages can increase at any time, and therefore the number of messages can increase at any time, and therefore the client
client cannot refer to a specific message using the MSN/UID '*'. cannot refer to a specific message using the MSN/UID '*'.
Internet-draft February 2008 Internet-draft February 2008
Example in the selected mailbox: Example in the selected mailbox:
S: * 444 EXISTS S: * 444 EXISTS
S: * 444 FETCH (UID 9999) S: * 444 FETCH (UID 9999)
And in another, without CONDSTORE: And in another, without CONDSTORE:
S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503)
5.3. MessageExpunge 5.3. MessageExpunge
If the expunged message(s) is/are in the selected mailbox, the If the expunged message(s) is/are in the selected mailbox, the server
server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] is being
is being used). used).
If a search context is in effect as specified in [CONTEXT], an If a search context is in effect as specified in [CONTEXT], an
ESEARCH REMOVEFROM will also be generated, if appropriate. ESEARCH REMOVEFROM will also be generated, if appropriate.
If the expunged message(s) is/are in another mailbox, the server If the expunged message(s) is/are in another mailbox, the server
sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the
relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be
included in the STATUS response. included in the STATUS response.
Note that if a client requests MessageExpunge, the meaning of a MSN Note that if a client requests MessageExpunge, the meaning of a MSN
skipping to change at page 10, line 7 skipping to change at page 10, line 7
These notifications are sent if an affected mailbox name was created These notifications are sent if an affected mailbox name was created
(with CREATE), deleted (with DELETE) or renamed (with RENAME). If a (with CREATE), deleted (with DELETE) or renamed (with RENAME). If a
mailbox is created or deleted, the mailbox itself and its parent are mailbox is created or deleted, the mailbox itself and its parent are
considered to be affected. considered to be affected.
The server notifies the client by sending an unsolicited LIST The server notifies the client by sending an unsolicited LIST
Internet-draft February 2008 Internet-draft February 2008
response for each affected mailbox name. If the mailbox name does response for each affected mailbox name. If the mailbox name does not
not refer to a mailbox after the event, the \Nonexistent flag MUST refer to a mailbox after the event, the \Nonexistent flag MUST be
be included. included.
For each selectable [[Alexey: is "selectable" important?]] mailbox For each selectable [[Alexey: is "selectable" important?]] mailbox
renamed, the server sends an extended LIST response [LISTEXT] for renamed, the server sends an extended LIST response [LISTEXT] for the
the new mailbox name, containing the OLDNAME extended data item with new mailbox name, containing the OLDNAME extended data item with the
the old mailbox name. When a mailbox is renamed, its children are old mailbox name. When a mailbox is renamed, its children are
renamed too. No additional MailboxName events are sent for children renamed too. No additional MailboxName events are sent for children
in this case. When INBOX is renamed, a new INBOX is assumed to be in this case. When INBOX is renamed, a new INBOX is assumed to be
created. No MailboxName event must be sent for INBOX in this case. created. No MailboxName event must be sent for INBOX in this case.
Example of a newly created mailbox: Example of a newly created mailbox:
S: * LIST () "/" "NewMailbox" S: * LIST () "/" "NewMailbox"
And a deleted mailbox: And a deleted mailbox:
S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox"
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Internet-draft February 2008 Internet-draft February 2008
SHOULD be returned in such METADATA responses. SHOULD be returned in such METADATA responses.
Example: Example:
S: * METADATA (/comment) S: * METADATA (/comment)
5.8. Notification Overflow 5.8. Notification Overflow
If the server is unable or unwilling to deliver as many If the server is unable or unwilling to deliver as many notifications
notifications as it is being asked to, it may disable notifications as it is being asked to, it may disable notifications for some or all
for some or all clients. It MUST notify these clients by sending an clients. It MUST notify these clients by sending an untagged "OK
untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE
NOTIFY NONE command had just been received. command had just been received.
Example: Example:
S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here...
5.9. ACL Changes 5.9. ACL Changes
Even if NOTIFY succeeds, it is still possible to loose access to the Even if NOTIFY succeeds, it is still possible to loose access to the
mailboxes monitoried at a later time. If this happens, the server mailboxes monitoried at a later time. If this happens, the server
MUST silently stop monitoring these mailboxes. If access is later MUST silently stop monitoring these mailboxes. If access is later
granted, the server MUST restart event monitoring. granted, the server MUST restart event monitoring.
6. Mailbox Specification 6. Mailbox Specification
Mailboxes to be monitored can be specified in several different Mailboxes to be monitored can be specified in several different ways.
ways.
If the client specifies monitoring of the same mailbox several Only 'selected' matches the currently selected mailbox. If the client
times, the first specification wins. A common example is asking for specifies monitoring of the same mailbox several times, the first
events on the selected mailbox and some named mailboxes. specification wins. A common example is asking for events on the
selected mailbox and some named mailboxes.
In this example, the client asks for MessageExpunge events for all In this example, the client asks for MessageExpunge events for all
personal mailboxes except the selected mailbox: personal mailboxes except the selected mailbox:
C: a notify set (selected (MessageNew (uid flags) flagchange)) C: a notify set (selected (MessageNew (uid flags) flagchange))
(personal (MessageNew FlagChange MessageExpunge)) (personal (MessageNew FlagChange MessageExpunge))
6.1. Selected 6.1. Selected
Selected refers to the mailbox selected using either SELECT or Selected refers to the mailbox selected using either SELECT or
EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP
skipping to change at page 13, line 28 skipping to change at page 13, line 28
Note that the EXISTS response MUST precede the ESEARCH response, and Note that the EXISTS response MUST precede the ESEARCH response, and
the FETCH response MUST follow the ESEARCH response. the FETCH response MUST follow the ESEARCH response.
No untagged FETCH response SHOULD be returned if a message becomes a No untagged FETCH response SHOULD be returned if a message becomes a
member of UPDATE SEARCH due to flag or annotation changes. member of UPDATE SEARCH due to flag or annotation changes.
8. Formal Syntax 8. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC4234]. [RFC3501] defines Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the
the non-terminals "capability", "command-auth", "mailbox", "mailbox- non-terminals "capability", "command-auth", "mailbox", "mailbox-
data", "resp-text-code" and "search-key". The "modifier-update" non- data", "resp-text-code" and "search-key". The "modifier-update" non-
terminal is defined in [CONTEXT]. terminal is defined in [CONTEXT].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
capability =/ "X-DRAFT-W03-NOTIFY" capability =/ "X-DRAFT-W03-NOTIFY"
;; [[Note to RFC Editor: change the capability ;; [[Note to RFC Editor: change the capability
;; name before publication]] ;; name before publication]]
command-auth =/ notify command-auth =/ notify
notify = "NOTIFY" SP notify = "NOTIFY" SP
(notify-add / notify-set / notify-none) (notify-set / notify-none)
notify-add = "ADD" [status-indicator] SP event-groups
; Add (prepend) registered notification
; events to the list of notification
; events. Newer events override older
; events.
[[Alexey: what about "most specific" event
overriding a pattern?]]
Internet-draft February 2008
notify-set = "SET" [status-indicator] SP event-groups notify-set = "SET" [status-indicator] SP event-groups
; Replace registered notification events ; Replace registered notification events
; with the specified list of events ; with the specified list of events [[Alexey:
what about "most specific" event overriding a
pattern?]]
notify-none = "NONE" notify-none = "NONE"
Internet-draft February 2008
; Cancel all registered notification ; Cancel all registered notification
; events. The client is not interested ; events. The client is not interested
; in receiving any events. ; in receiving any events.
status-indicator = SP "STATUS" status-indicator = SP "STATUS"
one-or-more-mailbox = mailbox / many-mailboxes one-or-more-mailbox = mailbox / many-mailboxes
many-mailboxes = "(" mailbox *(SP mailbox) ")" many-mailboxes = "(" mailbox *(SP mailbox) ")"
skipping to change at page 14, line 44 skipping to change at page 14, line 39
;; to receive any events for the specified ;; to receive any events for the specified
;; mailboxes. ;; mailboxes.
event = message-event event = message-event
/ mailbox-event / user-event / event-ext / mailbox-event / user-event / event-ext
message-match-criteria = "(" search-key ")" message-match-criteria = "(" search-key ")"
message-event = ( "MessageNew" [SP message-event = ( "MessageNew" [SP
"(" fetch-att *(SP fetch-att) ")" ] ) "(" fetch-att *(SP fetch-att) ")" ] )
/ "MessageExpunge" SP "MessageExpunge"
/ "FlagChange" SP message-match-criteria / "FlagChange" SP message-match-criteria
/ "AnnotationChange" SP message-match-criteria / "AnnotationChange" SP message-match-criteria
;; "MessageNew" includes "MessageAppend" from ;; "MessageNew" includes "MessageAppend" from
;; [MSGEVENT]. "FlagChange" is any of ;; [MSGEVENT]. "FlagChange" is any of
;; "MessageRead", "MessageTrash", "FlagsSet", ;; "MessageRead", "MessageTrash", "FlagsSet",
;; "FlagsClear" [MSGEVENT]. "MessageExpunge" ;; "FlagsClear" [MSGEVENT]. "MessageExpunge"
;; includes "MessageExpire" [MSGEVENT]. ;; includes "MessageExpire" [MSGEVENT].
Internet-draft February 2008
mailbox-event = "MailboxName" / mailbox-event = "MailboxName" /
"SubscriptionChange" / "MailboxMetadataChange" "SubscriptionChange" / "MailboxMetadataChange"
; "SubscriptionChange" includes ; "SubscriptionChange" includes
; MailboxSubscribe and MailboxUnSubscribe. ; MailboxSubscribe and MailboxUnSubscribe.
; "MailboxName" includes MailboxCreate, ; "MailboxName" includes MailboxCreate,
; "MailboxDelete" and "MailboxRename". ; "MailboxDelete" and "MailboxRename".
Internet-draft February 2008
user-event = "ServerMetadataChange" user-event = "ServerMetadataChange"
event-ext = atom event-ext = atom
;; For future extensions ;; For future extensions
oldname-extended-item = "OLDNAME" SP "(" mailbox ")" oldname-extended-item = "OLDNAME" SP "(" mailbox ")"
;; Extended data item (mbox-list-extended-item) ;; Extended data item (mbox-list-extended-item)
;; returned in a LIST response when a mailbox is ;; returned in a LIST response when a mailbox is
;; renamed. ;; renamed.
;; Note 1: the OLDNAME tag can be returned ;; Note 1: the OLDNAME tag can be returned
skipping to change at page 15, line 52 skipping to change at page 15, line 45
9. Security considerations 9. Security considerations
It is very easy for a client to deny itself service using NOTIFY: It is very easy for a client to deny itself service using NOTIFY:
Asking for all events on all mailboxes may work on a small server, Asking for all events on all mailboxes may work on a small server,
but with a big server can swamp the client's network connection or but with a big server can swamp the client's network connection or
processing capability. In the worst case, the server's processing processing capability. In the worst case, the server's processing
could also degrade the service it offers to other clients. could also degrade the service it offers to other clients.
Server authors should be aware that if a client issues requests and Server authors should be aware that if a client issues requests and
does not listen to the resulting responses, the TCP window can does not listen to the resulting responses, the TCP window can easily
easily fill up, and a careless server might block. This problem fill up, and a careless server might block. This problem exists in
plain IMAP, however this extension magnifies the problem.
Internet-draft February 2008
exists in plain IMAP, however this extension magnifies the problem.
This extensions makes it possible to retrieve messages immediately This extensions makes it possible to retrieve messages immediately
when they are added to the mailbox. This makes it wholly impractical when they are added to the mailbox. This makes it wholly impractical
to delete sensitive messages using programs like imapfilter. Using to delete sensitive messages using programs like imapfilter. Using
[SIEVE] or similar is much better. [SIEVE] or similar is much better.
Internet-draft February 2008
10. IANA considerations 10. IANA considerations
The IANA is requested to add NOTIFY to the list of IMAP extensions, The IANA is requested to add NOTIFY to the list of IMAP extensions,
http://www.iana.org/assignments/imap4-capabilities. http://www.iana.org/assignments/imap4-capabilities.
10.1. Initial LIST-EXTENDED extended data item registrations 10.1. Initial LIST-EXTENDED extended data item registrations
It is requested that the following entry be added to the LIST- It is requested that the following entry be added to the LIST-
EXTENDED extended data item registry [LISTEXT]: EXTENDED extended data item registry [LISTEXT]:
skipping to change at page 17, line 5 skipping to change at page 16, line 47
Owner/Change controller: iesg@ietf.org Owner/Change controller: iesg@ietf.org
11. Acknowedgements 11. Acknowedgements
The authors gratefully acknowledge the help of Peter Coates, Dave The authors gratefully acknowledge the help of Peter Coates, Dave
Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric
Burger. In particular, Peter Coates contributed lots of text and Burger. In particular, Peter Coates contributed lots of text and
useful suggestions to this document. useful suggestions to this document.
Internet-draft February 2008
Various examples are copied from other RFCs. Various examples are copied from other RFCs.
This document builds on one published and two unpublished drafts by This document builds on one published and two unpublished drafts by
the same authors. the same authors.
12. Normative References 12. Normative References
Internet-draft February 2008
[RFC2119] Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March Requirement Levels", RFC 2119, Harvard University, March
1997. 1997.
[RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997.
[RFC3501] Crispin, "Internet Message Access Protocol - Version [RFC3501] Crispin, "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, June 2003. 4rev1", RFC 3501, University of Washington, June 2003.
[RFC4234] Crocker, Overell, "Augmented BNF for Syntax [RFC5234] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, Brandenburg Specifications: ABNF", RFC 5234, Brandenburg
Internetworking, Demon Internet Ltd, October 2005. Internetworking, THUS plc, January 2008.
[RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC
RFC 4314, December 2005. 4314, December 2005.
[RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", RFC
RFC 4466, Isode Ltd., April 2006. 4466, Isode Ltd., April 2006.
[RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE
Operation or Quick Flag Changes Resynchronization", RFC Operation or Quick Flag Changes Resynchronization", RFC
4551, Isode Ltd., June 2006. 4551, Isode Ltd., June 2006.
[LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft-
ietf-imapext-list-extensions-18 (work in progress), IBM, ietf-imapext-list-extensions-18 (work in progress), IBM,
September 2006. September 2006.
[METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap-
annotatemore-12 (work in progress), Apple Computer, Inc., annotatemore-12 (work in progress), Apple Computer, Inc.,
December 2007. December 2007.
[MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store
Events", draft-ietf-lemonade-msgevent-03.txt (work in Events", draft-ietf-lemonade-msgevent-05.txt (work in
progress), Sun, July 2007. progress), Sun, January 2008.
[CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in
progress, draft-cridland-imap-context-03.txt, Isode, June progress, draft-cridland-imap-context-03.txt, Isode, June
2007. 2007.
Internet-draft February 2008
13. Informative References 13. Informative References
[SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick
Mailbox Resynchronization", draft-ietf-lemonade- Mailbox Resynchronization", draft-ietf-lemonade-reconnect-
reconnect-client-05.txt (work in progress), February client-06.txt (work in progress), September 2007.
2007.
Internet-draft February 2008
[EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker-
email-arch-09 (work in progress), March 2007. email-arch-10 (work in progress), February 2008.
14. Authors' Addresses 14. Authors' Addresses
Curtis King Curtis King
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
skipping to change at page 19, line 10 skipping to change at page 19, line 10
D-81671 Muenchen D-81671 Muenchen
Germany Germany
Email: arnt@oryx.com Email: arnt@oryx.com
Internet-draft February 2008 Internet-draft February 2008
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to Copyright (C) The IETF Trust (2008). This document is subject to the
the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 69 change blocks. 
175 lines changed or deleted 169 lines changed or added

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