doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc8579.txt b/doc/rfc/rfc8579.txt
new file mode 100644
index 0000000..519395d
--- /dev/null
+++ b/doc/rfc/rfc8579.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          S. Bosch
+Request for Comments: 8579                               Open Xchange Oy
+Category: Standards Track                                       May 2019
+ISSN: 2070-1721
+
+
+       Sieve Email Filtering: Delivering to Special-Use Mailboxes
+
+Abstract
+
+   The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows
+   clients to identify special-use mailboxes, e.g., where draft or sent
+   messages should be put.  This simplifies client configuration.  In
+   contrast, the Sieve mail filtering language (RFC 5228) currently has
+   no such capability.  This memo defines a Sieve extension that fills
+   this gap: it adds a test for checking whether a special-use attribute
+   is assigned for a particular mailbox or any mailbox, and it adds the
+   ability to file messages into a mailbox identified solely by a
+   special-use attribute.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8579.
+
+Copyright Notice
+
+   Copyright (c) 2019 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Bosch                        Standards Track                    [Page 1]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
+   3.  Test "specialuse_exists"  . . . . . . . . . . . . . . . . . .   3
+     3.1.  Equivalent IMAP Operations  . . . . . . . . . . . . . . .   4
+   4.  ":specialuse" Argument to "fileinto" Command  . . . . . . . .   5
+     4.1.  Mailboxes Created Implicitly by the "fileinto" Command  .   6
+     4.2.  Equivalent IMAP Operations  . . . . . . . . . . . . . . .   7
+   5.  Sieve Capability Strings  . . . . . . . . . . . . . . . . . .   8
+   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12
+
+1.  Introduction
+
+   Commonly, several mailboxes in an IMAP message store [IMAP] have a
+   special use.  For example, there can be a special-use mailbox for
+   storing the user's draft messages, for keeping copies of sent
+   messages, and for collecting spam messages that were classified as
+   such at delivery.  The SPECIAL-USE capability [SPECIAL-USE] of the
+   IMAP protocol defines mailbox attributes that identify these special
+   mailboxes explicitly to the client.  This way, client configuration
+   is simplified significantly.  Using the CREATE-SPECIAL-USE capability
+   [SPECIAL-USE], IMAP clients can also configure these attributes
+   dynamically based on user preference.
+
+   Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE]
+   currently cannot freely access these special-use mailbox attributes.
+   Particularly, the Sieve interpreter has no means to identify a
+   mailbox with a particular special-use attribute.  This would be very
+   useful, for example, to find the user's "Spam" mailbox at delivery.
+
+   In Sieve, limited access to the special-use attributes is provided
+   using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows
+   testing for the presence of a special-use attribute in the "/private/
+   specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox.  Still,
+   not all implementers will be willing to add the complexity of the
+   IMAP METADATA capability just to provide access to special-use
+   attributes to the Sieve interpreter.
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 2]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   This document defines an extension to the Sieve mail filtering
+   language that adds the ability to freely access mailbox special-use
+   attributes.  It adds a test called "specialuse_exists" that checks 1)
+   whether a special-use attribute is assigned for a particular mailbox
+   or 2) whether any of the user's personal mailboxes have a special-use
+   attribute assigned.  It also adds the ability to file messages into a
+   personal mailbox identified by a particular special-use attribute
+   rather than the mailbox's name.  This is achieved using the new
+   ":specialuse" argument for the "fileinto" command [SIEVE].
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in
+   all capitals, as shown here.
+
+   Conventions for notations are as described in Section 1.1 of [SIEVE],
+   including use of the "Usage:" label for the definition of the action
+   and the syntax of tagged arguments.
+
+   In [IMAP] examples, "C:" and "S:" indicate lines sent by the client
+   and server, respectively.  If such lines are wrapped without a new
+   "C:" or "S:" label, then the wrapping is for editorial clarity and is
+   not part of the command.
+
+3.  Test "specialuse_exists"
+
+   Usage:  specialuse_exists [<mailbox: string>]
+                             <special-use-attrs: string-list>
+
+   If the "mailbox" string argument is omitted, the "specialuse_exists"
+   test yields "true" if all of the following statements are true for
+   each of the special-use attributes listed in the special-use-attrs
+   argument:
+
+   a.  At least one mailbox exists in the user's personal namespace
+       [NAMESPACE] that has that particular special-use attribute
+       assigned.
+
+   b.  That mailbox allows the user in whose context the Sieve script
+       runs to "deliver" messages into it.
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 3]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   If the mailbox argument is specified, the "specialuse_exists" test
+   yields "true" if all of the following statements are true:
+
+   a.  The indicated mailbox exists.
+
+   b.  That mailbox allows the user in whose context the Sieve script
+       runs to "deliver" messages into it.
+
+   c.  That mailbox has all of the special-use attributes listed in the
+       special-use-attrs argument assigned to it.
+
+   Refer to the specification of the "mailboxexists" test in Section 3.1
+   of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of
+   messages into a mailbox is deemed possible.
+
+3.1.  Equivalent IMAP Operations
+
+   To clarify, the following IMAP protocol examples show a sequence of
+   [IMAP] commands that a client could send to perform an assessment
+   without Sieve that is equivalent to the "specialuse_exists" test.
+
+   First, the client queries which namespaces are available using the
+   NAMESPACE command [NAMESPACE]:
+
+   C: A01 NAMESPACE
+   S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
+   S: A01 OK NAMESPACE command completed
+
+   Subsequently, when no particular mailbox is of interest (i.e., the
+   "specialuse_exists" test has no mailbox argument), the client lists
+   all mailboxes with special-use attributes in the two returned
+   personal namespaces (this extended LIST command requires the LIST-
+   EXTENDED IMAP capability [LIST-EXTENDED]):
+
+   C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*")
+       RETURN (SPECIAL-USE)
+   S: * LIST (\Drafts) "/" INBOX/Drafts
+   S: * LIST (\Trash) "/" INBOX/Trash
+   S: * LIST (\Sent) "/" INBOX/Sent
+   S: * LIST (\Archive) "/" Archive/Default
+   S: A02 OK LIST command completed
+
+   Finally, using the MYRIGHTS command [IMAP-ACL], the client determines
+   the access rights it has for the mailbox or mailboxes that have all
+   the requested attributes assigned.  This way, it can determine
+   whether messages can be saved to any of those.  In this example, an
+   "\Archive" special-use mailbox is sought:
+
+
+
+
+Bosch                        Standards Track                    [Page 4]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   C: A03 MYRIGHTS Archive/Default
+   S: * MYRIGHTS Archive/Default lrwsip
+   S: A03 OK Myrights completed
+
+   The MYRIGHTS response indicates that the user has "insert" rights
+   [IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client
+   can deliver (APPEND) messages to that mailbox and that the Sieve
+   "specialuse_exists" test would yield "true" in this case.
+
+4.  ":specialuse" Argument to "fileinto" Command
+
+   Usage:  fileinto [:specialuse <special-use-attr: string>]
+                    <mailbox: string>
+
+   Normally, the "fileinto" command delivers the message in the mailbox
+   specified using its positional mailbox argument, which is the name of
+   the mailbox.  However, if the optional ":specialuse" argument is also
+   specified, the "fileinto" command first checks whether a mailbox
+   exists in the user's personal namespace [NAMESPACE] with the
+   specified special-use attribute assigned to it.  If that is the case,
+   that special-use mailbox is used for delivery instead.  If there is
+   no such mailbox or if the specified special-use attribute is unknown
+   to the implementation in general, the "fileinto" action proceeds as
+   it would without the ":specialuse" argument.
+
+   Summarizing, if the ":specialuse" argument is specified, the
+   "fileinto" command deals with two mailboxes that may or may not exist
+   and may, in fact, be equal:
+
+   o  A special-use mailbox in the user's personal namespace, which has
+      at least the special-use attribute specified with the
+      ":specialuse" argument assigned to it.  The name for this mailbox
+      is not relevant here; it is only identified by the assigned
+      special-use attribute.
+
+   o  The default mailbox named by the positional string argument of the
+      "fileinto" command, which is used when the special-use mailbox is
+      not found.
+
+   The special-use attribute specified with the ":specialuse" argument
+   conforms to the "use-attr" syntax described in Section 6 of RFC 6154
+   [SPECIAL-USE].  Implementations SHOULD handle an invalid special-use
+   attribute in the same way as an invalid mailbox name is handled.  The
+   string parameter of the ":specialuse" argument is not a constant
+   string, which means that variable substitutions are allowed when the
+   "variables" extension [VARIABLES] is active.  In that case, the
+   syntax of the special-use attribute is only verified at runtime.
+
+
+
+
+Bosch                        Standards Track                    [Page 5]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   If neither the special-use mailbox nor the default mailbox exists,
+   the "fileinto" action MUST proceed exactly as it does in case the
+   ":specialuse" argument is absent and the mailbox named by its
+   positional argument does not exist.  The various options for handling
+   this situation are described in Section 4.1 of RFC 5228 [SIEVE].
+
+   More than one mailbox in the user's personal namespace can have a
+   particular special-use attribute assigned.  If one of those mailboxes
+   is, in fact, the default mailbox named by the positional string
+   argument of the "fileinto" command, that mailbox MUST be used for
+   delivery.  If the default mailbox is not one of the options, the
+   mailbox that is chosen for delivery is implementation defined.
+   However, while the set of mailboxes to which the involved special-use
+   attribute are assigned remains unchanged, implementations SHOULD
+   ensure that the mailbox choice is made consistently, so that the same
+   mailbox is used every time.  Conversely, the chosen mailbox MAY
+   change once the assignments of the special-use attribute that are
+   relevant for the mailbox choice are changed (usually by user
+   interaction).
+
+   If delivery to the special-use mailbox fails for reasons not relating
+   to its existence, the Sieve interpreter MUST NOT subsequently attempt
+   delivery in the indicated default mailbox as a fallback.  Instead, it
+   MUST proceed exactly as it does in case the ":specialuse" argument is
+   absent and delivery to the mailbox named by its positional argument
+   fails.  This prevents the situation where messages are unexpectedly
+   spread over two mailboxes in case transient or intermittent delivery
+   failures occur.
+
+4.1.  Mailboxes Created Implicitly by the "fileinto" Command
+
+   Before attempting to deliver the message into the specified mailbox,
+   the "fileinto" command may implicitly create the mailbox if it does
+   not exist (see Section 4.1 of RFC 5228 [SIEVE]).  This optional
+   behavior can be requested explicitly using the "mailbox" extension
+   [SIEVE-MAILBOX], which adds the optional ":create" argument to the
+   "fileinto" command.  If the ":create" argument is specified with
+   "fileinto", it instructs the Sieve interpreter to unconditionally
+   create the specified mailbox if needed.  Note that the ":create"
+   argument has no effect when the implicit creation of mailboxes for
+   delivery is the default behavior.
+
+   When the ":specialuse" argument is present, this behavior does not
+   change; the Sieve interpreter will implicitly create the specified
+   default mailbox if needed.  This need arises when both the special-
+   use mailbox and the default mailbox are not found.
+
+
+
+
+
+Bosch                        Standards Track                    [Page 6]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   If the server implementation supports the CREATE-SPECIAL-USE
+   capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special-
+   use attributes to new mailboxes), it SHOULD assign the special-use
+   attribute specified with the ":specialuse" argument to the newly
+   created mailbox.
+
+4.2.  Equivalent IMAP Operations
+
+   To clarify, the following IMAP protocol examples show a sequence of
+   [IMAP] commands that a client could send to perform an action without
+   Sieve that is equivalent to the "fileinto" action with the
+   ":specialuse" argument.  The following Sieve script is assumed:
+
+   require "fileinto";
+   require "special-use";
+
+   fileinto :specialuse "\\Archive" "INBOX/Archive";
+
+   First, the client proceeds as in Section 3.1 to find out whether the
+   indicated special-use attribute is assigned to any mailbox in the
+   user's personal namespace.  If a matching special-use mailbox is
+   found, the message is delivered there using the IMAP APPEND command.
+   If no matching special-use mailbox is found, the client attempts to
+   deliver the message to the indicated default mailbox:
+
+   C: A04 APPEND INBOX/Archive {309}
+   S: A04 NO [TRYCREATE] Mailbox does not exist: INBOX/Archive
+
+   In this example, the default mailbox does not exist either.  In that
+   case, the client MAY create the default mailbox and assign the
+   indicated special-use attribute to it:
+
+   C: A05 CREATE INBOX/Archive (USE (\Archive))
+   S: A05 OK Create completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 7]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   Finally, the client completes the delivery:
+
+   C: A06 APPEND INBOX/Archive {309}
+   S: + OK
+   C: Date: Wed, 18 Jul 2018 22:00:09 +0200
+   C: From: mooch@owatagu.siam.example
+   C: To: Fred Foobar <foobar@Blurdybloop.example>
+   C: Subject: afternoon meeting
+   C: Message-Id: <Q234234-01012222@owatagu.siam.example>
+   C: MIME-Version: 1.0
+   C: Content-Type: text/plain; charset=UTF-8
+   C:
+   C: Hi Fred, do you think we can meet again at 3:30 tomorrow?
+   C:
+   S: A06 OK [APPENDUID 1533375901 2312] Append completed.
+
+5.  Sieve Capability Strings
+
+   A Sieve implementation that defines the "specialuse_exists" test and
+   the ":specialuse" argument for the "fileinto" command will advertise
+   the capability string "special-use".
+
+6.  Examples
+
+   The following example saves the message in the mailbox where messages
+   deemed to be junk mail are held.  This mailbox is identified using
+   the "\Junk" special-use attribute.  If no mailbox has this attribute
+   assigned, the message is filed into the mailbox named "Spam".  If the
+   mailbox named "Spam" does not exist either, the result of this Sieve
+   script is implementation dependent, e.g., it may trigger an error or
+   the mailbox may be created implicitly.
+
+   require "fileinto";
+   require "special-use";
+
+   fileinto :specialuse "\\Junk" "Spam";
+
+   The following very similar example explicitly handles the case in
+   which neither a "\Junk" special-use mailbox nor the "Spam" mailbox
+   exists.  In that case, a mailbox called "Spam" is created, and the
+   message is stored there.  Additionally, the "\Junk" special-use
+   attribute may be assigned to it.
+
+   require "fileinto";
+   require "special-use";
+   require "mailbox";
+
+   fileinto :specialuse "\\Junk" :create "Spam";
+
+
+
+Bosch                        Standards Track                    [Page 8]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   The following example is used in a Sieve script that is triggered
+   from an IMAP event rather than at message delivery [IMAPSIEVE].  This
+   Sieve script redirects messages to an automated recipient that
+   processes junk mail if those messages are copied or moved into a
+   mailbox that has the "\Junk" special-use attribute assigned.
+
+   require "imapsieve";
+   require "special-use";
+   require "environment";
+   require "variables";
+
+   if environment :contains "imap.mailbox" "*" {
+       set "mailbox" "${1}";
+   }
+
+   if allof(
+       environment "imap.cause" "COPY",
+       specialuse_exists "${mailbox}" "\\Junk") {
+       redirect "spam-report@example.org";
+   }
+
+7.  Security Considerations
+
+   Security considerations are discussed in [SIEVE], [VARIABLES], and
+   [SPECIAL-USE].  It is believed that this extension does not introduce
+   any additional security concerns.
+
+   Note that this specification explicitly restricts the special-use
+   mailbox to the user's personal namespace.  First, this avoids the
+   need to search the entire mail storage for mailboxes that have a
+   particular special-use attribute assigned.  This could put undue load
+   on the system, while shared special-use mailboxes are deemed of
+   limited use with the currently defined special-use attributes.
+   Secondly, it prevents security concerns with shared mailboxes that
+   have special-use attributes assigned that apply to all users.
+   Searching the entire mail storage for special-use mailboxes could
+   lead to messages unexpectedly or even maliciously being filed to
+   shared mailboxes.
+
+   This restriction could be lifted for particular future special-use
+   attributes, but such new attributes should have a clear application
+   for shared mailboxes, and the security concerns should be considered
+   carefully.
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 9]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+8.  IANA Considerations
+
+   IANA has registered the Sieve extension specified in this document in
+   the "Sieve Extensions" registry at <https://www.iana.org/assignments/
+   sieve-extensions>:
+
+      Capability name: special-use
+      Description:     adds a test for checking whether an IMAP
+                       special-use attribute is assigned for a
+                       particular mailbox or any mailbox; also adds
+                       the ability to file messages into a mailbox
+                       identified solely by a special-use attribute.
+      RFC number:      RFC 8579
+      Contact address: Sieve discussion list <sieve@ietf.org>
+
+9.  References
+
+9.1.  Normative References
+
+   [IMAP-METADATA]
+              Daboo, C., "The IMAP METADATA Extension", RFC 5464,
+              DOI 10.17487/RFC5464, February 2009,
+              <https://www.rfc-editor.org/info/rfc5464>.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [KEYWORDS-UPD]
+              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [NAMESPACE]
+              Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
+              DOI 10.17487/RFC2342, May 1998,
+              <https://www.rfc-editor.org/info/rfc2342>.
+
+   [SIEVE]    Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
+              Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
+              January 2008, <https://www.rfc-editor.org/info/rfc5228>.
+
+   [SIEVE-MAILBOX]
+              Melnikov, A., "The Sieve Mail-Filtering Language --
+              Extensions for Checking Mailbox Status and Accessing
+              Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March
+              2009, <https://www.rfc-editor.org/info/rfc5490>.
+
+
+
+Bosch                        Standards Track                   [Page 10]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+   [SPECIAL-USE]
+              Leiba, B. and J. Nicolson, "IMAP LIST Extension for
+              Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
+              March 2011, <https://www.rfc-editor.org/info/rfc6154>.
+
+   [VARIABLES]
+              Homme, K., "Sieve Email Filtering: Variables Extension",
+              RFC 5229, DOI 10.17487/RFC5229, January 2008,
+              <https://www.rfc-editor.org/info/rfc5229>.
+
+9.2.  Informative References
+
+   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+              <https://www.rfc-editor.org/info/rfc3501>.
+
+   [IMAP-ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
+              RFC 4314, DOI 10.17487/RFC4314, December 2005,
+              <https://www.rfc-editor.org/info/rfc4314>.
+
+   [IMAPSIEVE]
+              Leiba, B., "Support for Internet Message Access Protocol
+              (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,
+              November 2012, <https://www.rfc-editor.org/info/rfc6785>.
+
+   [LIST-EXTENDED]
+              Leiba, B. and A. Melnikov, "Internet Message Access
+              Protocol version 4 - LIST Command Extensions", RFC 5258,
+              DOI 10.17487/RFC5258, June 2008,
+              <https://www.rfc-editor.org/info/rfc5258>.
+
+Acknowledgements
+
+   Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison,
+   and Ned Freed for reviews and suggestions.
+
+   Thanks to the authors of RFC 5490 [SIEVE-MAILBOX], from which some
+   descriptive text in this document is borrowed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                   [Page 11]
+
+RFC 8579              Sieve: Special-Use Mailboxes              May 2019
+
+
+Author's Address
+
+   Stephan Bosch
+   Open Xchange Oy
+   Lars Sonckin kaari 12
+   Espoo  02600
+   Finland
+
+   Email: stephan.bosch@open-xchange.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                   [Page 12]
+