draft-ietf-imapext-list-extensions-05.txt   draft-ietf-imapext-list-extensions-06.txt 
IMAP Extensions Working Group B. Leiba IMAP Extensions Working Group B. Leiba
Internet Draft IBM T.J. Watson Research Center Internet Draft IBM T.J. Watson Research Center
Document: draft-ietf-imapext-list-extensions-05.txt April 2004 Document: draft-ietf-imapext-list-extensions-06.txt May 2004
Expires October 2004 Expires November 2004
IMAP4 LIST Command Extensions IMAP4 LIST Command Extensions
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at line 30 skipping to change at line 31
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.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as an Proposed Standard for the Internet Community. editor as an Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested, and should Discussion and suggestions for improvement are requested, and should
be sent to ietf-imapext@imc.org. This document will expire before 31 be sent to ietf-imapext@imc.org. This document will expire before 31
October 2004. Distribution of this memo is unlimited. November 2004. Distribution of this memo is unlimited.
This documents obsoletes RFC 3348 and updates RFC 2193.
Abstract Abstract
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we
have added extensions that have required specialized lists (see have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list [MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible. LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in set of commands to mix the different options, the set increasing in
skipping to change at line 54 skipping to change at line 57
exponential increase in specialized list commands. exponential increase in specialized list commands.
1. Conventions used in this document 1. Conventions used in this document
In examples, "C:" indicates lines sent by a client that is connected In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client. to a server. "S:" indicates lines sent by the server to the client.
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
used in this document as specified in RFC 2119 [Keywords]. used in this document as specified in RFC 2119 [Keywords].
2. Introduction 2. Introduction and overview
The extensions to the LIST command will be accomplished by amending The extensions to the LIST command will be accomplished by amending
the syntax to allow options to be specified. The list of options the syntax to allow options to be specified. The list of options
will replace the several commands that are currently used to mix and will replace the several commands that are currently used to mix and
match the information requested. The new syntax is backward- match the information requested. The new syntax is backward-
compatible, with no ambiguity: if the first word after the command compatible, with no ambiguity: if the first word after the command
name begins with a parenthesis, the new syntax is being used; if it name begins with a parenthesis, the new syntax is being used; if it
does not, it's in the original syntax. does not, it's in the original syntax.
By adding options to the LIST command, we are announcing the intent By adding options to the LIST command, we are announcing the intent
to phase out and eventually to deprecate the RLIST and RLSUB commands to phase out and eventually to deprecate the RLIST and RLSUB commands
described in [MboxRefer]. We are also defining the mechanism to described in [MboxRefer]. We are also defining the mechanism to
request extended mailbox information, such as is described in the request extended mailbox information, such as is described in the
"Child Mailbox Extension" [ChildMbox]. The base "Child Mailbox Extension" [ChildMbox]. The base
LSUB command is not deprecated by this extension; rather, this LSUB command is not deprecated by this extension; rather, this
extension adds a way to obtain subscription information with more extension adds a way to obtain subscription information with more
options, with those server implementations that support it. Clients options, with those server implementations that support it. Clients
that simply need a list of subscribed mailboxes, as provided by the that simply need a list of subscribed mailboxes, as provided by the
LSUB command, SHOULD continue to use that command. LSUB command, SHOULD continue to use that command.
This document defines an IMAP4 extension that is identified by the
capability string "LISTEXT". The LISTEXT extension makes the
following changes to the IMAP4 protocol, which are described in
more details in sections 3 and 4 of this document:
a. defines new syntax for LIST command options.
b. adds LIST command options: SUBSCRIBED, REMOTE and CHILDREN
c. adds new mailbox flags "\NonExistent", "\PlaceHolder",
"\HasChildren" and "\HasNoChildren".
3. LIST Command Options 3. LIST Command Options
The LIST command syntax is extended by adding a parenthesized list of The LIST command syntax is extended by adding a parenthesized list of
command options between the command name and the reference name (see command options between the command name and the reference name (see
the formal syntax in section 6 for specific details). Command the formal syntax in section 6 for specific details). Command
options will be defined in this document and in approved extension options will be defined in this document and in approved extension
documents; each option will be enabled by a capability string (one documents; each option will be enabled by a capability string (one
capability may enable multiple options), and a client MUST NOT send capability may enable multiple options), and a client MUST NOT send
an option for which the server has not advertised support. A server an option for which the server has not advertised support. A server
MUST respond to options it does not recognize with a NO response. MUST respond to options it does not recognize with a NO response.
skipping to change at line 85 skipping to change at line 98
3. LIST Command Options 3. LIST Command Options
The LIST command syntax is extended by adding a parenthesized list of The LIST command syntax is extended by adding a parenthesized list of
command options between the command name and the reference name (see command options between the command name and the reference name (see
the formal syntax in section 6 for specific details). Command the formal syntax in section 6 for specific details). Command
options will be defined in this document and in approved extension options will be defined in this document and in approved extension
documents; each option will be enabled by a capability string (one documents; each option will be enabled by a capability string (one
capability may enable multiple options), and a client MUST NOT send capability may enable multiple options), and a client MUST NOT send
an option for which the server has not advertised support. A server an option for which the server has not advertised support. A server
MUST respond to options it does not recognize with a NO response. MUST respond to options it does not recognize with a NO response.
This extension is identified by the capability string "LISTEXT", and This extension is identified by the capability string "LISTEXT", and
support for it is a prerequisite for any future extensions that support for it is a prerequisite for any future extensions that
require specialized forms of the LIST command. Such extensions MUST require specialized forms of the LIST command. Such extensions MUST
refer to this document and MUST add their function through command refer to this document and MUST add their function through command
options as described herein. This document also defines the "LIST- options as described herein.
SUBSCRIBED" capability string; see the "SUBSCRIBED" option below.
This extension also defines extensions to the LIST response, allowing This extension also defines extensions to the LIST response, allowing
a series of extended fields at the end, a parenthesized list of a series of extended fields at the end, a parenthesized list of tagged
attribute/value pairs. Each attribute is a string, each value may data (also referred to as "extended data item"). The first element of
be a string or a nested parenthesized list of the same an extended field is a tag, which identifies type of the data. Tags
attribute/value pairs. An example of this extended set might be MUST be registered with IANA, as described in section 8.5 of this
document. An example of such extended set might be
(("tablecloth" (("fringe" "lacy")("color" "white")))("X-Sample" ((tablecloth (("fringe" "lacy")("color" "white")))(X-Sample
"text")) "text"))
or... or...
(("tablecloth" ("fringe" "lacy"))("X-Sample" "text")) ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even more text"))
See the formal grammar, below, for the full syntatic details. See the formal grammar, below, for the full syntatic details.
The server MAY return data in the extended fields that was not solicited
by the client. The client MUST ignore all extended fields it doesn't
recognize.
The options defined in this specification are The options defined in this specification are
SUBSCRIBED - causes the LIST command to list subscribed SUBSCRIBED - causes the LIST command to list subscribed
mailboxes, rather than the actual mailboxes. This will often mailboxes, rather than the actual mailboxes. This will often
be a subset of the actual mailboxes. It's also possible for be a subset of the actual mailboxes. It's also possible for
this list to contain the names of mailboxes that don't exist. this list to contain the names of mailboxes that don't exist.
In any case, the list MUST include exactly those mailbox names In any case, the list MUST include exactly those mailbox names
that match the selection criteria and are subscribed to. This that match the selection criteria and are subscribed to. This
option is intended to supplement the LSUB command, and support option is intended to supplement the LSUB command.
for it is optional -- a server that supports the SUBSCRIBED
option indicates so through the LIST-SUBSCRIBED capability.
Of particular note are the mailbox flags as returned by this Of particular note are the mailbox flags as returned by this
option, compared with what is returned by LSUB. With the option, compared with what is returned by LSUB. With the
latter, the flags returned may not reflect the actual flag latter, the flags returned may not reflect the actual flag
status on the mailbox, and the \NoSelect flag has a special status on the mailbox, and the \NoSelect flag has a special
meaning (it indicates that this mailbox is not, itself, meaning (it indicates that this mailbox is not, itself,
subscribed, but that it has child mailboxes that are). With subscribed, but that it has child mailboxes that are). With
the SUBSCRIBED option described here, the flags are accurate the SUBSCRIBED option described here, the flags are accurate
and complete, and have no special meanings. and complete, and have no special meanings.
"LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
and some servers must do significant extra work to respond to and some servers must do significant extra work to respond to
"LIST (SUBSCRIBED)". Because of this, clients SHOULD continue "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue
to use "LSUB" unless they specifically want the additional to use "LSUB" unless they specifically want the additional
information offered by "LIST (SUBSCRIBED)". At the same time, information offered by "LIST (SUBSCRIBED)".
servers SHOULD support the LIST-SUBSCRIBED capability even if
it entails extra work, because a client that wants the
information will still obtain it by using LSUB followed by a
series of LIST commands, so servers might as well make it
easier.
This option defines a new mailbox flag, "\NonExistent", that This option defines a new mailbox flag, "\NonExistent", that
indicates that a mailbox is subscribed to, but does not indicates that a mailbox is subscribed to, but does not
actually exist. The "\NonExistent" flag MUST be supported and actually exist. The "\NonExistent" flag MUST be supported and
MUST be accurately computed. MUST be accurately computed.
REMOTE - causes the LIST command to show remote mailboxes as REMOTE - causes the LIST command to show remote mailboxes as
well as local ones, as described in [MboxRefer]. This option well as local ones, as described in [MboxRefer]. This option
is intended to replace the RLIST command and, in conjunction is intended to replace the RLIST command and, in conjunction
with the SUBSCRIBED option, the RLSUB command. This option is with the SUBSCRIBED option, the RLSUB command. This option is
skipping to change at line 306 skipping to change at line 316
list-options = "(" [option *(SP option)] ")" list-options = "(" [option *(SP option)] ")"
mailbox-list = "(" [mbx-list-flags] ")" SP mailbox-list = "(" [mbx-list-flags] ")" SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
[SP mbox-list-extended] [SP mbox-list-extended]
mbox-list-extended = "(" [mbox-list-extended-item mbox-list-extended = "(" [mbox-list-extended-item
*(SP mbox-list-extended-item)] ")" *(SP mbox-list-extended-item)] ")"
mbox-list-extended-item = "(" string SP (nstring / mbox-list-extended-item = "(" mbox-list-extended-item-data ")"
mbox-list-extended-item) ")"
/ mailbox-list-extended mbox-list-extended-item-data = mbox-list-extended-item-tag SP nstring-list
mbox-list-extended-item-tag = vendor-tag / standard-tag
; A tag registration template is described in section
; 8.5 of this document.
vendor-tag = "V-" atom
; a vendor specific tag for extended list data
standard-tag = atom
; a tag for extended list data defined in a Standard
; Track or Experimental RFC.
nstring-list = nstring /
"(" [nstring-list *(SP nstring-list)] ")"
;; a recursive list definition
mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\PlaceHolder" mbox-list-oflag = child-mbox-flag / "\NonExistent" / "\PlaceHolder"
option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" /
option-extension option-extension
; An option registration template is described in section
; 8.3 of this document.
option-extension = atom option-extension = option-vendor / option-public
option-vendor = "V-" atom
; a vendor specific option
option-public = atom
; an option defined in a Standard Track or
; Experimental RFC
7. Security Considerations 7. Security Considerations
This document describes syntactic changes to the specification of the This document describes syntactic changes to the specification of the
IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
command has the same security considerations as those commands. They command has the same security considerations as those commands. They
are described in [IMAP4] and [MboxRefer]. are described in [IMAP4] and [MboxRefer].
The Child Mailbox Extension provides a client a more efficient means The Child Mailbox Extension provides a client a more efficient means
of determining whether a particular mailbox has children. If a of determining whether a particular mailbox has children. If a
skipping to change at line 338 skipping to change at line 372
\HasNoChildren attribute. In many cases, however, a server may not \HasNoChildren attribute. In many cases, however, a server may not
be able to efficiently compute whether a user has access to all child be able to efficiently compute whether a user has access to all child
mailboxes. If such a server responds with a \HasChildren attribute, mailboxes. If such a server responds with a \HasChildren attribute,
when in fact the currently authenticated user does not have access to when in fact the currently authenticated user does not have access to
any child mailboxes, potentially more information is conveyed about any child mailboxes, potentially more information is conveyed about
the mailbox than intended. In most situations this will not be a the mailbox than intended. In most situations this will not be a
security concern, because if information regarding whether a mailbox security concern, because if information regarding whether a mailbox
has children is considered sensitive, a user would not be granted has children is considered sensitive, a user would not be granted
access to that mailbox in the first place. access to that mailbox in the first place.
8. References 8. IANA Considerations
8.1. Normative References 8.1. Guidelines for IANA
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version It is requested that IANA creates two new registries for LISTEXT
4rev1", RFC 3501, University of Washington, March 2003. options and LISTEXT extended response data. The templates and
the initial registrations are detailed below.
[MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193; 8.2. Registration procedure and Change control
Microsoft Corporation; September 1997.
Registration of a LISTEXT option is done by filling in the template
in section 8.3 and sending it via electronic mail to <iana@iana.org>.
Registration of a LISTEXT extended data item is done by filling in the
template in section 8.5 and sending it via electronic mail to <iana@iana.org>.
IANA has the right to reject obviously bogus registrations, but will
perform no review of claims made in the registration form.
A LISTEXT option/extended data item name that starts with "V-" is reserved
for vendor specific options/extended data items. All options, whether
they are vendor specific or global, should be registered with IANA.
If a LISTEXT extended data item is returned as a result of requesting
a particular LISTEXT option, the name of the option SHOULD be used
as the name of the LISTEXT extended data item.
LISTEXT option/extended data item names are case insensitive.
While the registration procedures do not require it, authors of LISTEXT
options/extended data items are encouraged to seek community review and
comment whenever that is feasible. Authors may seek community review by
posting a specification of their proposed mechanism as an Internet-
Draft. LISTEXT options/extended data items intended for widespread use
should be standardized through the normal IETF process, when appropriate.
Comments on registered LISTEXT options/extended response data should
first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG
mailing list.
Submitters of comments may, after a reasonable attempt to contact the
owner, request IANA to attach their comment to the registration itself.
If IANA approves of this, the comment will be
made accessible in conjunction with the registration LISTEXT options/
extended response data itself.
Once a LISTEXT registration has been published by IANA, the
author may request a change to its definition. The change request
follows the same procedure as the registration request.
The owner of a LISTEXT registration may pass responsibility for the
registered option/extended data item to another person or agency by
informing IANA; this can be done without discussion or review.
The IESG may reassign responsibility for a LISTEXT option/extended data item.
The most common case of this will be to enable changes to be made to
mechanisms where the author of the registration has died, moved out
of contact or is otherwise unable to make changes that are important
to the community.
LISTEXT registrations may not be deleted; mechanisms which are
no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such LISTEXT options/extended data
items will be clearly marked in the lists published by IANA.
The IESG is considered to be the owner of all LISTEXT options/extended data items
which are on the IETF standards track.
8.3. Registration template for LISTEXT options
To: iana@iana.org
Subject: Registration of LISTEXT option X
LISTEXT option name:
LISTEXT option description:
Published specification (optional, recommended):
Security considerations:
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Person & email address to contact for further information:
Owner/Change controller:
(Any other information that the author deems interesting may be
added below this line.)
8.4. Initial LISTEXT option registrations
It is requested that the LISTEXT option registry is being populated
with the following entries:
1)
To: iana@iana.org
Subject: Registration of LISTEXT option SUBSCRIBED
LISTEXT option name: SUBSCRIBED
LISTEXT option description: Causes the LIST command to list
subscribed mailboxes, rather than the actual mailboxes.
Published specification : this RFC, section 3.
Security considerations: this RFC, section 7.
Intended usage: COMMON
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: IESG <iesg@ietf.org>
2)
To: iana@iana.org
Subject: Registration of LISTEXT option REMOTE
LISTEXT option name: REMOTE
LISTEXT option description: causes the LIST command to return
remote mailboxes as well as local ones, as described in
RFC 2193.
Published specification : this RFC, section 3.
Security considerations: this RFC, section 7.
Intended usage: COMMON
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: IESG <iesg@ietf.org>
3)
To: iana@iana.org
Subject: Registration of LISTEXT option CHILDREN
LISTEXT option name: CHILDREN
LISTEXT option description: Requests mailbox child information.
Published specification : this RFC, sections 3 and 4.
Published specification : this RFC
Security considerations: this RFC, section 7.
Intended usage: COMMON
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Owner/Change controller: IESG <iesg@ietf.org>
8.5. Registration template for LISTEXT extended data item
To: iana@iana.org
Subject: Registration of LISTEXT extended data item X
LISTEXT extended data item tag:
LISTEXT extended data item description:
Which LISTEXT option(s) causes this extended data item
to be returned (if any):
Published specification (optional, recommended):
Security considerations:
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Person & email address to contact for further information:
Owner/Change controller:
(Any other information that the author deems interesting may be
added below this line.)
9. References
9.1. Normative References
[Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate
Requirement Levels"; RFC 2119; Harvard University; March 1997. Requirement Levels"; RFC 2119; Harvard University; March 1997.
[ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
8.2. Informative References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003.
[MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193;
Microsoft Corporation; September 1997.
[ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension"; [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension";
RFC 3348; Microsoft Corporation; July 2002. RFC 3348; Microsoft Corporation; July 2002.
9. Acknowledgements 10. Acknowledgements
Mike Gahrns and Raymond Cheng of Microsoft Corporation originally Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
devised the Child Mailbox Extension and proposed it in 1997; the devised the Child Mailbox Extension and proposed it in 1997; the
idea, as well as most of the text in section 4, is theirs. idea, as well as most of the text in section 4, is theirs.
This document is the result of discussions on the IMAP4 mailing list This document is the result of discussions on the IMAP4 mailing list
and is meant to reflect consensus of this group. In particular, and is meant to reflect consensus of this group. In particular,
Mark Crispin, Cyrus Daboo, Timo Sirainen, Ken Murchison, Alexey Mark Crispin, Cyrus Daboo, Timo Sirainen, Ken Murchison, Alexey
Melnikov, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry Melnikov, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry
Greenfield and Pete Maclean were active participants in this Greenfield, Phlip Guenther and Pete Maclean were active participants
discussion or made suggestions to this document. in this discussion or made suggestions to this document.
10. Author's Address 11. Author's Address
Barry Leiba Barry Leiba
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
30 Saw Mill River Road 30 Saw Mill River Road
Hawthorne, NY 10532 Hawthorne, NY 10532
Phone: 1-914-784-7941 Phone: 1-914-784-7941
Email: leiba@watson.ibm.com Email: leiba@watson.ibm.com
11. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society 2004. All Rights Reserved. Copyright (C) The Internet Society 2004. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 414 skipping to change at line 628
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by Funding for the RFC Editor function is currently provided by
the Internet Society. the Internet Society.
12. Intellectual Property 13. Intellectual Property
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 to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/