< draft-ietf-appsawg-multimailbox-search-01.txt   draft-ietf-appsawg-multimailbox-search-02.txt >
Applications Area Working Group B. Leiba Applications Area Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 6237 (if approved) A. Melnikov Updates: 4466 (if approved) A. Melnikov
Updates: 4466 (if approved) Isode Limited Obsoletes: 6237 (if approved) Isode Limited
Intended status: Standards Track June 3, 2014 Intended status: Standards Track July 21, 2014
Expires: December 5, 2014 Expires: January 20, 2015
IMAP4 Multimailbox SEARCH Extension IMAP4 Multimailbox SEARCH Extension
draft-ietf-appsawg-multimailbox-search-01 draft-ietf-appsawg-multimailbox-search-02
Abstract Abstract
The IMAP4 specification allows the searching of only the selected The IMAP4 specification allows the searching of only the selected
mailbox. A user often wants to search multiple mailboxes, and a mailbox. A user often wants to search multiple mailboxes, and a
client that wishes to support this must issue a series of SELECT and client that wishes to support this must issue a series of SELECT and
SEARCH commands, waiting for each to complete before moving on to the SEARCH commands, waiting for each to complete before moving on to the
next. This extension allows a client to search multiple mailboxes next. This extension allows a client to search multiple mailboxes
with one command, limiting round trips delay, and not requiring with one command, limiting round trips delay, and not requiring
disruption of the currently selected mailbox. This extension also disruption of the currently selected mailbox. This extension also
uses MAILBOX and TAG fields in ESEARCH responses, allowing a client uses MAILBOX and TAG fields in ESEARCH responses, allowing a client
to pipeline the searches if it chooses. This document updates RFC to pipeline the searches if it chooses. This document updates RFC
4466 and obsoletes RFC 6237. 4466 and obsoletes RFC 6237.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 5, 2014. This Internet-Draft will expire on January 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2. New ESEARCH Command . . . . . . . . . . . . . . . . . . . . . 3 2. New ESEARCH Command . . . . . . . . . . . . . . . . . . . . . 3
2.1. The ESEARCH Response . . . . . . . . . . . . . . . . . . . 4 2.1. The ESEARCH Response . . . . . . . . . . . . . . . . . . . . 4
2.2. Source Options: Specifying Mailboxes to Search . . . . . . 5 2.2. Source Options: Specifying Mailboxes to Search . . . . . . . 5
2.3. Strictness in Search Matches . . . . . . . . . . . . . . . 7 2.3. Strictness in Search Matches . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Server-Side Limitations on Search Volume . . . . . . . . . . 6
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Changes Since RFC 6237 . . . . . . . . . . . . . . . . . . . 10 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Changes Since RFC 6237 . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The IMAP4 specification allows the searching of only the selected The IMAP4 specification allows the searching of only the selected
mailbox. A user often wants to search multiple mailboxes, and a mailbox. A user often wants to search multiple mailboxes, and a
client that wishes to support this must issue a series of SELECT and client that wishes to support this must issue a series of SELECT and
SEARCH commands, waiting for each to complete before moving on to the SEARCH commands, waiting for each to complete before moving on to the
next. The commands can't be pipelined, because the server might run next. The commands can't be pipelined, because the server might run
them in parallel, and the untagged SEARCH responses could not then be them in parallel, and the untagged SEARCH responses could not then be
distinguished from each other. distinguished from each other.
skipping to change at page 3, line 23 skipping to change at page 3, line 20
client to distinguish which responses go with which search (and client to distinguish which responses go with which search (and
which mailbox). A client can safely pipeline these search which mailbox). A client can safely pipeline these search
commands without danger of confusion. The addition of the MAILBOX commands without danger of confusion. The addition of the MAILBOX
and UIDVALIDITY fields updates the search-correlator item defined and UIDVALIDITY fields updates the search-correlator item defined
in [RFC4466]. in [RFC4466].
This extension was previously published as experimental. There is This extension was previously published as experimental. There is
now implementation experience, giving confidence in the protocol, so now implementation experience, giving confidence in the protocol, so
this document puts the extension on the Standards Track, with some this document puts the extension on the Standards Track, with some
minor updates that were informed by the implementation experience. minor updates that were informed by the implementation experience.
[[CREF1: RFC Editor: Please remove this paragraph at publication.]] [[RFC Editor: Please remove this paragraph at publication.]]
1.1. Conventions Used in This Document 1.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 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 5, line 6 skipping to change at page 4, line 49
Source options describe which mailboxes must be searched for Source options describe which mailboxes must be searched for
messages. An ESEARCH command with source options does not affect messages. An ESEARCH command with source options does not affect
which mailbox, if any, is currently selected, regardless of which which mailbox, if any, is currently selected, regardless of which
mailboxes are searched. mailboxes are searched.
For each mailbox satisfying the source options, a single ESEARCH For each mailbox satisfying the source options, a single ESEARCH
response MUST be returned if any messages in that mailbox match the response MUST be returned if any messages in that mailbox match the
search criteria. An ESEARCH response MUST NOT be returned for search criteria. An ESEARCH response MUST NOT be returned for
mailboxes that contain no matching messages. This is true even when mailboxes that contain no matching messages. This is true even when
result options such as MIN, MAX, and COUNT are specified (see result options such as MIN, MAX, and COUNT are specified (see Section
Section 3.1 of [RFC4731]), and the values returned (lowest UID 3.1 of [RFC4731]), and the values returned (lowest UID matched,
matched, highest UID matched, and number of messages matched, highest UID matched, and number of messages matched, respectively)
respectively) apply to the mailbox reported in that ESEARCH response. apply to the mailbox reported in that ESEARCH response.
Note that it is possible for an ESEARCH command to return no untagged Note that it is possible for an ESEARCH command to return no untagged
responses (no ESEARCH responses at all), in the case that there are responses (no ESEARCH responses at all), in the case that there are
no matches to the search in any of the mailboxes that satisfy the no matches to the search in any of the mailboxes that satisfy the
source options. Clients can detect this situation by finding the source options. Clients can detect this situation by finding the
tagged OK response without having received any matching untagged tagged OK response without having received any matching untagged
ESEARCH responses. ESEARCH responses.
Each ESEARCH response MUST contain the MAILBOX, TAG, and UIDVALIDITY Each ESEARCH response MUST contain the MAILBOX, TAG, and UIDVALIDITY
correlators. Correlators allow clients to issue several ESEARCH correlators. Correlators allow clients to issue several ESEARCH
skipping to change at page 7, line 20 skipping to change at page 6, line 55
for example, "swim" to "swam" and "swum" as well, or only doing full for example, "swim" to "swam" and "swum" as well, or only doing full
word matching (where "swim" will not match "swimming"). This is word matching (where "swim" will not match "swimming"). This is
covered by the "Fuzzy Search" extension to IMAP [RFC6203], and that covered by the "Fuzzy Search" extension to IMAP [RFC6203], and that
extension is compatible with this one and can be combined with it. extension is compatible with this one and can be combined with it.
Whether or not Fuzzy Search is implemented or used, this extension Whether or not Fuzzy Search is implemented or used, this extension
explicitly allows flexible searching with respect to TEXT and BODY explicitly allows flexible searching with respect to TEXT and BODY
searches. Servers MAY use fuzzy text matching in multimailbox searches. Servers MAY use fuzzy text matching in multimailbox
searches. searches.
2.4. Server-Side Limitations on Search Volume
To avoid having a search use more than a reasonable share of server
resources, servers MAY apply limits that go beyond loop protection,
such as limits on the number of mailboxes that may be searched at
once, and/or limits on the number or total size of messages searched.
A server can apply those limits up front, responding with "NO
[LIMIT]" if a limit is exceeded (see [RFC5530] for information about
response codes). Alternatively, a server can process the search and
terminate it when a limit is exceeded, responding with "OK [LIMIT]"
and returning partial results. Note that searches that return
partial results can cause complexity for client implementations and
confusion to users.
3. Examples 3. Examples
In the following example, note that two ESEARCH commands are In the following example, note that two ESEARCH commands are
pipelined, and that the server is running them in parallel, pipelined, and that the server is running them in parallel,
interleaving a response to the second search amid the responses to interleaving a response to the second search amid the responses to
the first (watch the tags). the first (watch the tags).
C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2") C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2")
subject "chad" subject "chad"
skipping to change at page 7, line 49 skipping to change at page 7, line 45
S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY
1111111) UID ALL 50003,50006,50009,50012 1111111) UID ALL 50003,50006,50009,50012
S: tag2 OK done S: tag2 OK done
4. Formal Syntax 4. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234]. Terms not defined here are Form (ABNF) as described in [RFC5234]. Terms not defined here are
taken from [RFC3501], [RFC5465], or [RFC4466]. taken from [RFC3501], [RFC5465], or [RFC4466].
command-auth =/ esearch command-auth =/ esearch
; Update definition from IMAP base [RFC3501]. ; Update definition from IMAP base [RFC3501].
; Add new "esearch" command. ; Add new "esearch" command.
command-select =/ esearch command-select =/ esearch
; Update definition from IMAP base [RFC3501]. ; Update definition from IMAP base [RFC3501].
; Add new "esearch" command. ; Add new "esearch" command.
filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox) filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox)
; Update definition from IMAP Notify [RFC5465]. ; Update definition from IMAP Notify [RFC5465].
; Add new "subtree-one" selector. ; Add new "subtree-one" selector.
filter-mailboxes-selected = "selected" filter-mailboxes-selected = "selected"
; Update definition from IMAP Notify [RFC5465]. ; Update definition from IMAP Notify [RFC5465].
; We forbid the use of "selected-delayed". ; We forbid the use of "selected-delayed".
one-correlator = ("TAG" SP tag-string) / ("MAILBOX" SP astring) / one-correlator = ("TAG" SP tag-string) / ("MAILBOX" SP astring) /
("UIDVALIDITY" SP nz-number) ("UIDVALIDITY" SP nz-number)
; Each correlator MUST appear exactly once. ; Each correlator MUST appear exactly once.
scope-option = scope-option-name [SP scope-option-value] scope-option = scope-option-name [SP scope-option-value]
; No options defined here. Syntax for future extensions. ; No options defined here. Syntax for future extensions.
scope-option-name = tagged-ext-label scope-option-name = tagged-ext-label
; No options defined here. Syntax for future extensions. ; No options defined here. Syntax for future extensions.
scope-option-value = tagged-ext-val scope-option-value = tagged-ext-val
; No options defined here. Syntax for future extensions. ; No options defined here. Syntax for future extensions.
scope-options = scope-option *(SP scope-option) scope-options = scope-option *(SP scope-option)
; A given option may only appear once. ; A given option may only appear once.
; No options defined here. Syntax for future extensions. ; No options defined here. Syntax for future extensions.
esearch = "ESEARCH" [SP esearch-source-opts] esearch = "ESEARCH" [SP esearch-source-opts]
[SP search-return-opts] SP search-program [SP search-return-opts] SP search-program
search-correlator = SP "(" one-correlator *(SP one-correlator) ")" search-correlator = SP "(" one-correlator *(SP one-correlator) ")"
; Updates definition in IMAP4 ABNF [RFC4466]. ; Updates definition in IMAP4 ABNF [RFC4466].
esearch-source-opts = "IN" SP "(" source-mbox [SP esearch-source-opts = "IN" SP "(" source-mbox [SP
"(" scope-options ")"] ")" "(" scope-options ")"] ")"
source-mbox = filter-mailboxes *(SP filter-mailboxes) source-mbox = filter-mailboxes *(SP filter-mailboxes)
; "filter-mailboxes" is defined in IMAP Notify [RFC5465]. ; "filter-mailboxes" is defined in IMAP Notify [RFC5465].
; See updated definition of filter-mailboxes-other, above. ; See updated definition of filter-mailboxes-other, above.
; See updated definition of filter-mailboxes-selected, above. ; See updated definition of filter-mailboxes-selected, above.
5. Security Considerations 5. Security Considerations
This new IMAP ESEARCH command allows a single command to search many This new IMAP ESEARCH command allows a single command to search many
mailboxes at once. On the one hand, a client could do that by mailboxes at once. On the one hand, a client could do that by
sending many IMAP SEARCH commands. On the other hand, this makes it sending many IMAP SEARCH commands. On the other hand, this makes it
easier for a client to overwork a server, by sending a single command easier for a client to overwork a server, by sending a single command
that results in an expensive search of tens of thousands of that results in an expensive search of tens of thousands of
mailboxes. Server implementations need to be aware of that, and mailboxes. Server implementations need to be aware of that, and
provide mechanisms that prevent a client from adversely affecting provide mechanisms that prevent a client from adversely affecting
other users. Limitations on the number of mailboxes that may be other users. Limitations on the number of mailboxes that may be
searched in one command, and/or on the server resources that will be searched in one command, and/or on the server resources that will be
devoted to responding to a single client, are reasonable limitations devoted to responding to a single client, are reasonable limitations
for an implementation to impose. for an implementation to impose (see also Section 2.4.
Implementations MUST, of course, apply access controls appropriately, Implementations MUST, of course, apply access controls appropriately,
limiting a user's access to ESEARCH in the same way its access is limiting a user's access to ESEARCH in the same way its access is
limited for any other IMAP commands. This extension has no data- limited for any other IMAP commands. This extension has no data-
access risks beyond what may be there in the unextended IMAP access risks beyond what may be there in the unextended IMAP
implementation. implementation.
Mailboxes matching the source options for which the logged-in user Mailboxes matching the source options for which the logged-in user
lacks sufficient rights MUST be ignored by the ESEARCH command lacks sufficient rights MUST be ignored by the ESEARCH command
processing (see the paragraph about this in Section 2.2). In processing (see the paragraph about this in Section 2.2). In
particular, any attempt to distinguish insufficient access from particular, any attempt to distinguish insufficient access from non-
non-existent mailboxes may expose information about the mailbox existent mailboxes may expose information about the mailbox hierarchy
hierarchy that isn't otherwise available to the client. that isn't otherwise available to the client.
If "subtree" is specified, the server MUST defend against loops in If "subtree" is specified, the server MUST defend against loops in
the hierarchy (see the paragraph about this in Section 2.2). the hierarchy (see the paragraph about this in Section 2.2).
6. IANA Considerations 6. IANA Considerations
The "IMAP Capabilities" registry is currently located at The "IMAP Capabilities" registry is currently located at <http://
<http://www.iana.org/assignments/imap-capabilities#imap- www.iana.org/assignments/imap-capabilities>.
capabilities-1>.
IANA is asked to change the reference for the IMAP capability IANA is asked to change the reference for the IMAP capability
"MULTISEARCH" to point to this document. "MULTISEARCH" to point to this document.
7. Implementation Status 7. Implementation Status
[[CREF2: RFC Editor: Please remove this section at publication.]] [[RFC Editor: Please remove this section at publication.]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in RFC this Internet-Draft, and is based on a proposal described in RFC
6982. The description of implementations in this section is 6982. The description of implementations in this section is
intended to assist the IETF in its decision processes in intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors. information presented here that was supplied by IETF contributors.
skipping to change at page 10, line 41 skipping to change at page 10, line 22
8. Changes Since RFC 6237 8. Changes Since RFC 6237
o Change to Standards Track. o Change to Standards Track.
o Added paragraph about duplicate mailboxes. o Added paragraph about duplicate mailboxes.
o Added Section 2.3 about fuzzy search. o Added Section 2.3 about fuzzy search.
o Added Section 7, "Implementation Status". o Added Section 7, "Implementation Status".
[[CREF3: RFC Editor: Please remove this bullet at publication.]] [[RFC Editor: Please remove this bullet at publication.]]
9. Acknowledgements 9. Acknowledgments
The authors gratefully acknowledge feedback provided by Timo The authors gratefully acknowledge feedback provided by Timo
Sirainen, Peter Coates, Arnt Gulbrandsen, and Chris Newman. Sirainen, Peter Coates, Arnt Gulbrandsen, and Chris Newman.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 11, line 37 skipping to change at page 11, line 8
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
SEARCH Result", RFC 5182, March 2008. SEARCH Result", RFC 5182, March 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
July 2008. July 2008.
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP [RFC5465] Gulbrandsen, A., King, C. and A. Melnikov, "The IMAP
NOTIFY Extension", RFC 5465, February 2009. NOTIFY Extension", RFC 5465, February 2009.
[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530, May
2009.
10.2. Informative References 10.2. Informative References
[RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC [RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC
6203, March 2011. 6203, March 2011.
Authors' Addresses Authors' Addresses
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
skipping to change at page 12, line 4 skipping to change at page 11, line 27
6203, March 2011. 6203, March 2011.
Authors' Addresses Authors' Addresses
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/ URI: http://www.melnikov.ca/
 End of changes. 32 change blocks. 
62 lines changed or deleted 78 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/