draft-ietf-extra-quota-02.txt   draft-ietf-extra-quota-03.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Internet-Draft Isode
Intended status: Standards Track July 1, 2020 Intended status: Standards Track November 17, 2020
Expires: January 2, 2021 Expires: May 21, 2021
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-02 draft-ietf-extra-quota-03
Abstract Abstract
The QUOTA extension of the Internet Message Access Protocol (RFC The QUOTA extension of the Internet Message Access Protocol (RFC
3501) permits administrative limits on resource usage (quotas) to be 3501) permits administrative limits on resource usage (quotas) to be
manipulated through the IMAP protocol. manipulated through the IMAP protocol.
This memo obsoletes RFC 2087, but attempts to remain backwards This memo obsoletes RFC 2087, but attempts to remain backwards
compatible whenever possible. compatible whenever possible.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 2, 2021. This Internet-Draft will expire on May 21, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6
4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7
4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11
5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12
6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16 13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Document Conventions 1. Document Conventions
In protocol examples, this document uses a prefix of "C: " to denote In protocol examples, this document uses a prefix of "C: " to denote
lines sent by the client to the server, and "S: " for lines sent by lines sent by the client to the server, and "S: " for lines sent by
the server to the client. Lines prefixed with "// " are comments the server to the client. Lines prefixed with "// " are comments
explaining the previous protocol line. These prefixes and comments explaining the previous protocol line. These prefixes and comments
are not part of the protocol. Lines without any of these prefixes are not part of the protocol. Lines without any of these prefixes
are continuations of the previous line, and no line break is present are continuations of the previous line, and no line break is present
in the protocol unless specifically mentioned. in the protocol unless specifically mentioned.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
Limits will be specified as, and MUST be represented as, an integer. Limits will be specified as, and MUST be represented as, an integer.
0 indicates that any usage is prohibited. 0 indicates that any usage is prohibited.
Limits may be hard or soft - that is, an implementation MAY choose, Limits may be hard or soft - that is, an implementation MAY choose,
or be configured, to disallow any command if the limit on a resource or be configured, to disallow any command if the limit on a resource
is or would be exceeded. is or would be exceeded.
All resources which the server handles must be advertised in a All resources which the server handles must be advertised in a
CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-".
For compatability with RFC 2087 [RFC2087], a client which discovers
resources available on the server which are not advertised through
this mechanism MUST treat them as if they were completely opaque, and
without any meaning.
The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
(Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in
this document. this document.
3.2. Quota Root 3.2. Quota Root
Each mailbox has zero or more implementation-defined named "quota Each mailbox has zero or more implementation-defined named "quota
roots". Each quota root has zero or more resource limits (quotas). roots". Each quota root has zero or more resource limits (quotas).
All mailboxes that share the same named quota root share the resource All mailboxes that share the same named quota root share the resource
skipping to change at page 8, line 32 skipping to change at page 8, line 32
is entirely optional. is entirely optional.
S: S0002 NO Cannot change system limit S: S0002 NO Cannot change system limit
4.1.4. New STATUS attributes 4.1.4. New STATUS attributes
DELETED and DELETED-STORAGE status data items allow to estimate the DELETED and DELETED-STORAGE status data items allow to estimate the
amount of resource freed by an EXPUNGE on a mailbox. amount of resource freed by an EXPUNGE on a mailbox.
DELETED status data item requests the server to return the number of DELETED status data item requests the server to return the number of
messages with \Deleted flag set. messages with \Deleted flag set. DELETED status data item is only
required to be implemented when the server advertises QUOTA=RES-
MESSAGE capability.
DELETED-STORAGE status data item requests the server to return the DELETED-STORAGE status data item requests the server to return the
amount of storage space that can be reclaimed by performing EXPUNGE amount of storage space that can be reclaimed by performing EXPUNGE
on the mailbox. The server SHOULD return the exact value, however it on the mailbox. The server SHOULD return the exact value, however it
is recognized that the server may have to do non-trivial amount of is recognized that the server may have to do non-trivial amount of
work to calculate it. If the calculation of the exact value would work to calculate it. If the calculation of the exact value would
take a long time, the server MAY instead return the sum of take a long time, the server MAY instead return the sum of
RFC822.SIZEs of messages with the \Deleted flag set. RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE
status data item is only required to be implemented when the server
advertises QUOTA=RES-STORAGE capability.
Example: Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE
[...] [...]
[...] [...]
C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
// 12 messages, 4 of which would be deleted when an EXPUNGE // 12 messages, 4 of which would be deleted when an EXPUNGE
happens. happens.
S: S0003 OK Status complete. S: S0003 OK Status complete.
4.2. Responses 4.2. Responses
The following responses may be sent by the server. The following responses may be sent by the server.
4.2.1. QUOTA 4.2.1. QUOTA
skipping to change at page 11, line 32 skipping to change at page 11, line 37
use the usage figure for anything other than informational purposes, use the usage figure for anything other than informational purposes,
for example, they MUST NOT refuse to APPEND a message if the limit for example, they MUST NOT refuse to APPEND a message if the limit
less the usage is smaller than the RFC822.SIZE divided by 1024 of the less the usage is smaller than the RFC822.SIZE divided by 1024 of the
message, but it MAY warn about such condition. message, but it MAY warn about such condition.
The usage figure may change as a result of performing actions not The usage figure may change as a result of performing actions not
associated with adding new messages to the mailbox, such as SEARCH, associated with adding new messages to the mailbox, such as SEARCH,
since this may increase the amount of metadata included in the since this may increase the amount of metadata included in the
calculations. calculations.
When the server supports this resource type, it MUST also support
DELETED-STORAGE status data item.
Support for this resource MUST be indicated by the server by Support for this resource MUST be indicated by the server by
advertising the CAPABILITY "QUOTA=RES-STORAGE". advertising the CAPABILITY "QUOTA=RES-STORAGE".
A resource named the same was also given as an example in RFC2087 A resource named the same was also given as an example in RFC2087
[RFC2087]. This document provides a more precise definition. [RFC2087]. This document provides a more precise definition.
5.2. MESSAGE 5.2. MESSAGE
The number of messages stored within the mailboxes governed by the The number of messages stored within the mailboxes governed by the
quota root. This MUST be an exact number, however, clients MUST NOT quota root. This MUST be an exact number, however, clients MUST NOT
assume that a change in the usage indicates a change in the number of assume that a change in the usage indicates a change in the number of
messages available, since the quota root may include mailboxes the messages available, since the quota root may include mailboxes the
client has no access to. client has no access to.
When the server supports this resource type, it MUST also support
DELETED status data item.
Support for this resource MUST be indicated by the server by Support for this resource MUST be indicated by the server by
advertising the CAPABILITY "QUOTA=RES-MESSAGE". advertising the CAPABILITY "QUOTA=RES-MESSAGE".
A resource named the same was also given as an example in RFC2087 A resource named the same was also given as an example in RFC2087
[RFC2087]. This document provides a more precise definition. [RFC2087]. This document provides a more precise definition.
5.3. MAILBOX 5.3. MAILBOX
The number of mailboxes governed by the quota root. This MUST be an The number of mailboxes governed by the quota root. This MUST be an
exact number, however, clients MUST NOT assume that a change in the exact number, however, clients MUST NOT assume that a change in the
skipping to change at page 12, line 34 skipping to change at page 12, line 45
6. Interaction with IMAP ACL extension (RFC 4314) 6. Interaction with IMAP ACL extension (RFC 4314)
This section lists [RFC4314] rights required to execute quota related This section lists [RFC4314] rights required to execute quota related
commands when both RFC 4314 and this document are implemented. commands when both RFC 4314 and this document are implemented.
+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
| Operations\Ri | l | r | s | w | i | c | x | t | e | a | Any | Non | | Operations\Ri | l | r | s | w | i | c | x | t | e | a | Any | Non |
| ghts | | | | | | | | | | | | | | ghts | | | | | | | | | | | | |
+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
| GETQUOTA | | | | | | | | | | | | * | | GETQUOTA | | | | | | | | | | | | + |
| GETQUOTAROOT | | * | | | | | | | | | | * | | GETQUOTAROOT | | * | | | | | | | | | | * |
| SETQUOTA | | | | | | | | | | + | | | | SETQUOTA | | | | | | | | | | + | | |
+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
See Section 4 of RFC 4314 for conventions used in this table. See Section 4 of RFC 4314 for conventions used in this table.
[[CREF2: The above table needs to be reviewed based on feedback from [[CREF2: The above table needs to be reviewed based on feedback from
existing and planned implementations.]] existing and planned implementations.]]
7. Formal syntax 7. Formal syntax
skipping to change at page 14, line 12 skipping to change at page 14, line 22
resource-usage = number64 resource-usage = number64
;; must be less than corresponding resource-limit ;; must be less than corresponding resource-limit
capability-quota = capa-quota-res / "QUOTASET" capability-quota = capa-quota-res / "QUOTASET"
;; One or more capa-quota-res must be returned. ;; One or more capa-quota-res must be returned.
;; Also "QUOTASET" can optionally be returned. ;; Also "QUOTASET" can optionally be returned.
capa-quota-res = "QUOTA=RES-" resource-name capa-quota-res = "QUOTA=RES-" resource-name
status-att =/ "DELETED" / "DELETED-STORAGE" status-att =/ "DELETED" / "DELETED-STORAGE"
;; DELETED status data item MUST be supported
;; when "QUOTA=RES-MESSAGE" capability is
;; advertised.
;; DELETED-STORAGE status data item MUST be
;; supported when "QUOTA=RES-STORAGE" capability
;; is advertised.
status-att-val =/ ("DELETED" SP number) / status-att-val =/ status-att-deleted /
("DELETED-STORAGE" SP number64) status-att-deleted-storage
status-att-deleted =/ "DELETED" SP number
;; DELETED status data item MUST be supported
;; when "QUOTA=RES-MESSAGE" capability is
;; advertised.
status-att-deleted-storage =/ "DELETED-STORAGE" SP number64
;; DELETED-STORAGE status data item MUST be
;; supported when "QUOTA=RES-STORAGE" capability
;; is advertised.
resp-text-code =/ "OVERQUOTA" [SP tag] resp-text-code =/ "OVERQUOTA" [SP tag]
number64 = 1*DIGIT ;; Unsigned 63-bit integer. number64 = 1*DIGIT
;; Unsigned 63-bit integer.
;; (0 <= n <= 9,223,372,036,854,775,807) ;; (0 <= n <= 9,223,372,036,854,775,807)
8. Security Considerations 8. Security Considerations
Implementors should be careful to make sure the implementation of Implementors should be careful to make sure the implementation of
these commands does not violate the site's security policy. The these commands does not violate the site's security policy. The
resource usage of other users is likely to be considered confidential resource usage of other users is likely to be considered confidential
information and should not be divulged to unauthorized persons. information and should not be divulged to unauthorized persons.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 14, line 44 skipping to change at page 15, line 28
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
IANA is requested to update definition of the QUOTA extension to IANA is requested to update definition of the QUOTA extension to
point to this document. point to this document.
IANA is also requested to create a new registry for IMAP quota IANA is also requested to create a new registry for IMAP quota
resource types. Registration policy for this registry is resource types. Registration policy for this registry is
"Specification Required". When registering a new quota resource "Specification Required". When registering a new quota resource
type, the registrant need to provide the following: Name of the quota type, the registrant need to provide the following: Name of the quota
resource type, Author/Change Controller name and email address, short resource type, Author/Change Controller name and email address, short
description and a reference to a specification that describes the description, extra (if any) required and optional IMAP commands/
responses, and a reference to a specification that describes the
quota resource type in more details. quota resource type in more details.
This document includes initial registrations for the following IMAP This document includes initial registrations for the following IMAP
quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2),
MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See
details below. details below.
IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4
capabilities registry and add a pointer to this document and to the capabilities registry and add a pointer to this document and to the
IMAP quota resource type registry established above. IMAP quota resource type registry established above.
skipping to change at page 15, line 20 skipping to change at page 16, line 4
"QUOTA=" prefix for future IETF stream standard track or experimental "QUOTA=" prefix for future IETF stream standard track or experimental
extensions to this document. extensions to this document.
9.1. Registrations of IMAP Quota Resource Types 9.1. Registrations of IMAP Quota Resource Types
Name of the quota resource type: STORAGE Name of the quota resource type: STORAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com> Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org> Change Controller: IESG <iesg@ietf.org>
Description: The physical space estimate, in units of 1024 octets, Description: The physical space estimate, in units of 1024 octets,
of the mailboxes governed by the quota root. of the mailboxes governed by the quota root.
Extra required IMAP commands/responses: DELETED-STORAGE STATUS
request data item and response data item
Extra optional IMAP commands/responses: N/A
Reference: Section 5.1 of RFCXXXX Reference: Section 5.1 of RFCXXXX
Name of the quota resource type: MESSAGE Name of the quota resource type: MESSAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com> Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org> Change Controller: IESG <iesg@ietf.org>
Description: The number of messages stored within the mailboxes Description: The number of messages stored within the mailboxes
governed by the quota root. governed by the quota root.
Extra required IMAP commands/responses: DELETED STATUS request data
item and response data item
Extra optional IMAP commands/responses: N/A
Reference: Section 5.2 of RFCXXXX Reference: Section 5.2 of RFCXXXX
Name of the quota resource type: MAILBOX Name of the quota resource type: MAILBOX
Author: Alexey Melnikov <alexey.melnikov@isode.com> Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org> Change Controller: IESG <iesg@ietf.org>
Description: The number of mailboxes governed by the quota root. Description: The number of mailboxes governed by the quota root.
Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A
Reference: Section 5.3 of RFCXXXX Reference: Section 5.3 of RFCXXXX
Name of the quota resource type: Name of the quota resource type:
Author: Alexey Melnikov <alexey.melnikov@isode.com> Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org> Change Controller: IESG <iesg@ietf.org>
Description: The maximum size of all annotations [RFC5257], in units Description: The maximum size of all annotations [RFC5257], in units
of 1024 octets, associated with all messages in the mailboxes of 1024 octets, associated with all messages in the mailboxes
governed by the quota root. [[CREF3: Recheck against the final governed by the quota root. [[CREF3: Recheck against the final
description of "ANNOTATION-STORAGE".]] description of "ANNOTATION-STORAGE".]]
Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A
Reference: Section 5.4 of RFCXXXX Reference: Section 5.4 of RFCXXXX
10. Open Issues 10. Open Issues
'"OVERQUOTA" SP tag' form has syntactic issues, as "tag" allows for '"OVERQUOTA" SP tag' form has syntactic issues, as "tag" allows for
"]", which is not allowed in response codes. Should we drop this "]", which is not allowed in response codes. Should we drop this
variant or change IMAP4rev2 to disallow "]" in tags? variant or change IMAP4rev2 to disallow "]" in tags?
Should "DELETED" status item be required to be implemented for
anything other than QUOTA-RES=MESSAGE? Similarly, should "DELETED-
STORAGE" status item be required to be implemented for anything other
than QUOTA-RES=STORAGE?
11. Contributors 11. Contributors
Dave Cridland wrote lots of text in an earlier draft that became the Dave Cridland wrote lots of text in an earlier draft that became the
basis for this document. basis for this document.
12. Acknowledgments 12. Acknowledgments
Editors of this document would like to thank the following people who Editors of this document would like to thank the following people who
provided useful comments or participated in discussions that lead to provided useful comments or participated in discussions that lead to
this update to RFC 2087: this update to RFC 2087:
 End of changes. 24 change blocks. 
35 lines changed or deleted 71 lines changed or added

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