1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc2342.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,563 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                         M. Gahrns
    1.11 +Request for Comments: 2342                                    Microsoft
    1.12 +Category: Standards Track                                     C. Newman
    1.13 +                                                               Innosoft
    1.14 +                                                               May 1998
    1.15 +
    1.16 +
    1.17 +                            IMAP4 Namespace
    1.18 +
    1.19 +Status of this Memo
    1.20 +
    1.21 +   This document specifies an Internet standards track protocol for the
    1.22 +   Internet community, and requests discussion and suggestions for
    1.23 +   improvements.  Please refer to the current edition of the "Internet
    1.24 +   Official Protocol Standards" (STD 1) for the standardization state
    1.25 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.26 +
    1.27 +Copyright Notice
    1.28 +
    1.29 +   Copyright (C) The Internet Society (1998).  All Rights Reserved.
    1.30 +
    1.31 +1. Abstract
    1.32 +
    1.33 +   IMAP4 [RFC-2060] does not define a default server namespace. As a
    1.34 +   result, two common namespace models have evolved:
    1.35 +
    1.36 +   The "Personal Mailbox" model, in which the default namespace that is
    1.37 +   presented consists of only the user's personal mailboxes. To access
    1.38 +   shared mailboxes, the user must use an escape mechanism to reach
    1.39 +   another namespace.
    1.40 +
    1.41 +   The "Complete Hierarchy" model, in which the default namespace that
    1.42 +   is presented includes the user's personal mailboxes along with any
    1.43 +   other mailboxes they have access to.
    1.44 +
    1.45 +   These two models, create difficulties for certain client operations.
    1.46 +   This document defines a NAMESPACE command that allows a client to
    1.47 +   discover the prefixes of namespaces used by a server for personal
    1.48 +   mailboxes, other users' mailboxes, and shared mailboxes.  This allows
    1.49 +   a client to avoid much of the manual user configuration that is now
    1.50 +   necessary when mixing and matching IMAP4 clients and servers.
    1.51 +
    1.52 +2. Conventions used in this document
    1.53 +
    1.54 +   In examples, "C:" and "S:" indicate lines sent by the client and
    1.55 +   server respectively.  If such lines are wrapped without a new "C:" or
    1.56 +   "S:" label, then the wrapping is for editorial clarity and is not
    1.57 +   part of the command.
    1.58 +
    1.59 +
    1.60 +
    1.61 +Gahrns & Newman             Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 2342                    IMAP4 Namespace                     May 1998
    1.64 +
    1.65 +
    1.66 +   Personal Namespace: A namespace that the server considers within the
    1.67 +   personal scope of the authenticated user on a particular connection.
    1.68 +   Typically, only the authenticated user has access to mailboxes in
    1.69 +   their Personal Namespace. It is the part of the namespace that
    1.70 +   belongs to the user that is allocated for mailboxes. If an INBOX
    1.71 +   exists for a user, it MUST appear within the user's personal
    1.72 +   namespace.  In the typical case, there SHOULD be only one Personal
    1.73 +   Namespace on a server.
    1.74 +
    1.75 +   Other Users' Namespace: A namespace that consists of mailboxes from
    1.76 +   the Personal Namespaces of other users.  To access mailboxes in the
    1.77 +   Other Users' Namespace, the currently authenticated user MUST be
    1.78 +   explicitly granted access rights.  For example, it is common for a
    1.79 +   manager to grant to their secretary access rights to their mailbox.
    1.80 +   In the typical case, there SHOULD be only one Other Users' Namespace
    1.81 +   on a server.
    1.82 +
    1.83 +   Shared Namespace: A namespace that consists of mailboxes that are
    1.84 +   intended to be shared amongst users and do not exist within a user's
    1.85 +   Personal Namespace.
    1.86 +
    1.87 +   The namespaces a server uses MAY differ on a per-user basis.
    1.88 +
    1.89 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.90 +   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
    1.91 +   document are to be interpreted as described in [RFC-2119].
    1.92 +
    1.93 +3. Introduction and Overview
    1.94 +
    1.95 +   Clients often attempt to create mailboxes for such purposes as
    1.96 +   maintaining a record of sent messages (e.g. "Sent Mail") or
    1.97 +   temporarily saving messages being composed (e.g. "Drafts").  For
    1.98 +   these clients to inter-operate correctly with the variety of IMAP4
    1.99 +   servers available, the user must enter the prefix of the Personal
   1.100 +   Namespace used by the server.  Using the NAMESPACE command, a client
   1.101 +   is able to automatically discover this prefix without manual user
   1.102 +   configuration.
   1.103 +
   1.104 +   In addition, users are often required to manually enter the prefixes
   1.105 +   of various namespaces in order to view the mailboxes located there.
   1.106 +   For example, they might be required to enter the prefix of #shared to
   1.107 +   view the shared mailboxes namespace. The NAMESPACE command allows a
   1.108 +   client to automatically discover the namespaces that are available on
   1.109 +   a server. This allows a client to present the available namespaces to
   1.110 +   the user in what ever manner it deems appropriate.  For example, a
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Gahrns & Newman             Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.120 +
   1.121 +
   1.122 +   client could choose to initially display only personal mailboxes, or
   1.123 +   it may choose to display the complete list of mailboxes available,
   1.124 +   and initially position the user at the root of their Personal
   1.125 +   Namespace.
   1.126 +
   1.127 +   A server MAY choose to make available to the NAMESPACE command only a
   1.128 +   subset of the complete set of namespaces the server supports. To
   1.129 +   provide the ability to access these namespaces, a client SHOULD allow
   1.130 +   the user the ability to manually enter a namespace prefix.
   1.131 +
   1.132 +4. Requirements
   1.133 +
   1.134 +   IMAP4 servers that support this extension MUST list the keyword
   1.135 +   NAMESPACE in their CAPABILITY response.
   1.136 +
   1.137 +   The NAMESPACE command is valid in the Authenticated and Selected
   1.138 +   state.
   1.139 +
   1.140 +5. NAMESPACE Command
   1.141 +
   1.142 +   Arguments: none
   1.143 +
   1.144 +   Response:  an untagged NAMESPACE response that contains the prefix
   1.145 +                 and hierarchy delimiter to the server's Personal
   1.146 +                 Namespace(s), Other Users' Namespace(s), and Shared
   1.147 +                 Namespace(s) that the server wishes to expose. The
   1.148 +                 response will contain a NIL for any namespace class
   1.149 +                 that is not available. Namespace_Response_Extensions
   1.150 +                 MAY be included in the response.
   1.151 +                 Namespace_Response_Extensions which are not on the IETF
   1.152 +                 standards track, MUST be prefixed with an "X-".
   1.153 +
   1.154 +   Result:    OK - Command completed
   1.155 +                 NO - Error: Can't complete command
   1.156 +                 BAD - argument invalid
   1.157 +
   1.158 +   Example 5.1:
   1.159 +   ===========
   1.160 +
   1.161 +      < A server that supports a single personal namespace.  No leading
   1.162 +      prefix is used on personal mailboxes and "/" is the hierarchy
   1.163 +      delimiter.>
   1.164 +
   1.165 +      C: A001 NAMESPACE
   1.166 +      S: * NAMESPACE (("" "/")) NIL NIL
   1.167 +      S: A001 OK NAMESPACE command completed
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Gahrns & Newman             Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.176 +
   1.177 +
   1.178 +   Example 5.2:
   1.179 +   ===========
   1.180 +
   1.181 +      < A user logged on anonymously to a server.  No personal mailboxes
   1.182 +      are associated with the anonymous user and the user does not have
   1.183 +      access to the Other Users' Namespace.  No prefix is required to
   1.184 +      access shared mailboxes and the hierarchy delimiter is "." >
   1.185 +
   1.186 +      C: A001 NAMESPACE
   1.187 +      S: * NAMESPACE NIL NIL (("" "."))
   1.188 +      S: A001 OK NAMESPACE command completed
   1.189 +
   1.190 +   Example 5.3:
   1.191 +   ===========
   1.192 +
   1.193 +      < A server that contains a Personal Namespace and a single Shared
   1.194 +      Namespace. >
   1.195 +
   1.196 +      C: A001 NAMESPACE
   1.197 +      S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
   1.198 +      S: A001 OK NAMESPACE command completed
   1.199 +
   1.200 +   Example 5.4:
   1.201 +   ===========
   1.202 +
   1.203 +      < A server that contains a Personal Namespace, Other Users'
   1.204 +      Namespace and multiple Shared Namespaces.  Note that the hierarchy
   1.205 +      delimiter used within each namespace can be different. >
   1.206 +
   1.207 +      C: A001 NAMESPACE
   1.208 +      S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
   1.209 +         ("#public/" "/")("#ftp/" "/")("#news." "."))
   1.210 +      S: A001 OK NAMESPACE command completed
   1.211 +
   1.212 +   The prefix string allows a client to do things such as automatically
   1.213 +   creating personal mailboxes or LISTing all available mailboxes within
   1.214 +   a namespace.
   1.215 +
   1.216 +   Example 5.5:
   1.217 +   ===========
   1.218 +
   1.219 +      < A server that supports only the Personal Namespace, with a
   1.220 +      leading prefix of INBOX to personal mailboxes and a hierarchy
   1.221 +      delimiter of ".">
   1.222 +
   1.223 +      C: A001 NAMESPACE
   1.224 +      S: * NAMESPACE (("INBOX." ".")) NIL  NIL
   1.225 +      S: A001 OK NAMESPACE command completed
   1.226 +
   1.227 +
   1.228 +
   1.229 +Gahrns & Newman             Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.232 +
   1.233 +
   1.234 +      < Automatically create a mailbox to store sent items.>
   1.235 +
   1.236 +      C: A002 CREATE "INBOX.Sent Mail"
   1.237 +      S: A002 OK CREATE command completed
   1.238 +
   1.239 +   Although typically a server will support only a single Personal
   1.240 +   Namespace, and a single Other User's Namespace, circumstances exist
   1.241 +   where there MAY be multiples of these, and a client MUST be prepared
   1.242 +   for them.   If a client is configured such that it is required to
   1.243 +   create a certain mailbox, there can be circumstances where it is
   1.244 +   unclear which Personal Namespaces it should create the mailbox in.
   1.245 +   In these situations a client SHOULD let the user select which
   1.246 +   namespaces to create the mailbox in.
   1.247 +
   1.248 +   Example 5.6:
   1.249 +   ===========
   1.250 +
   1.251 +      < In this example, a server supports 2 Personal Namespaces.  In
   1.252 +      addition to the regular Personal Namespace, the user has an
   1.253 +      additional personal namespace to allow access to mailboxes in an
   1.254 +      MH format mailstore. >
   1.255 +
   1.256 +      < The client is configured to save a copy of all mail sent by the
   1.257 +      user into a mailbox called 'Sent Mail'.  Furthermore, after a
   1.258 +      message is deleted from a mailbox, the client is configured to
   1.259 +      move that message to a mailbox called 'Deleted Items'.>
   1.260 +
   1.261 +      < Note that this example demonstrates how some extension flags can
   1.262 +      be passed to further describe the #mh namespace. >
   1.263 +
   1.264 +      C: A001 NAMESPACE
   1.265 +      S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
   1.266 +         NIL NIL
   1.267 +      S: A001 OK NAMESPACE command completed
   1.268 +
   1.269 +      < It is desired to keep only one copy of sent mail. It is unclear
   1.270 +      which Personal Namespace the client should use to create the 'Sent
   1.271 +      Mail' mailbox.  The user is prompted to select a namespace and
   1.272 +      only one 'Sent Mail' mailbox is created. >
   1.273 +
   1.274 +      C: A002 CREATE "Sent Mail"
   1.275 +      S: A002 OK CREATE command completed
   1.276 +
   1.277 +      < The client is designed so that it keeps two 'Deleted Items'
   1.278 +      mailboxes, one for each namespace. >
   1.279 +
   1.280 +      C: A003 CREATE "Delete Items"
   1.281 +      S: A003 OK CREATE command completed
   1.282 +
   1.283 +
   1.284 +
   1.285 +Gahrns & Newman             Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.288 +
   1.289 +
   1.290 +      C: A004 CREATE "#mh/Deleted Items"
   1.291 +      S: A004 OK CREATE command completed
   1.292 +
   1.293 +   The next level of hierarchy following the Other Users' Namespace
   1.294 +   prefix SHOULD consist of <username>, where <username> is a user name
   1.295 +   as per the IMAP4 LOGIN or AUTHENTICATE command.
   1.296 +
   1.297 +   A client can construct a LIST command by appending a "%" to the Other
   1.298 +   Users' Namespace prefix to discover the Personal Namespaces of other
   1.299 +   users that are available to the currently authenticated user.
   1.300 +
   1.301 +   In response to such a LIST command, a server SHOULD NOT return user
   1.302 +   names that have not granted access to their personal mailboxes to the
   1.303 +   user in question.
   1.304 +
   1.305 +   A server MAY return a LIST response containing only the names of
   1.306 +   users that have explicitly granted access to the user in question.
   1.307 +
   1.308 +   Alternatively, a server MAY return NO to such a LIST command,
   1.309 +   requiring that a user name be included with the Other Users'
   1.310 +   Namespace prefix before listing any other user's mailboxes.
   1.311 +
   1.312 +   Example 5.7:
   1.313 +   ===========
   1.314 +
   1.315 +      < A server that supports providing a list of other user's
   1.316 +      mailboxes that are accessible to the currently logged on user. >
   1.317 +
   1.318 +      C: A001 NAMESPACE
   1.319 +      S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
   1.320 +      S: A001 OK NAMESPACE command completed
   1.321 +
   1.322 +      C: A002 LIST "" "Other Users/%"
   1.323 +      S: * LIST () "/" "Other Users/Mike"
   1.324 +      S: * LIST () "/" "Other Users/Karen"
   1.325 +      S: * LIST () "/" "Other Users/Matthew"
   1.326 +      S: * LIST () "/" "Other Users/Tesa"
   1.327 +      S: A002 OK LIST command completed
   1.328 +
   1.329 +   Example 5.8:
   1.330 +   ===========
   1.331 +
   1.332 +      < A server that does not support providing a list of other user's
   1.333 +      mailboxes that are accessible to the currently logged on user.
   1.334 +      The mailboxes are listable if the client includes the name of the
   1.335 +      other user with the Other Users' Namespace prefix. >
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Gahrns & Newman             Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.344 +
   1.345 +
   1.346 +      C: A001 NAMESPACE
   1.347 +      S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
   1.348 +      S: A001 OK NAMESPACE command completed
   1.349 +
   1.350 +      < In this example, the currently logged on user has access to the
   1.351 +      Personal Namespace of user Mike, but the server chose to suppress
   1.352 +      this information in the LIST response.  However, by appending the
   1.353 +      user name Mike (received through user input) to the Other Users'
   1.354 +      Namespace prefix, the client is able to get a listing of the
   1.355 +      personal mailboxes of user Mike. >
   1.356 +
   1.357 +      C: A002 LIST "" "#Users/%"
   1.358 +      S: A002 NO The requested item could not be found.
   1.359 +
   1.360 +      C: A003 LIST "" "#Users/Mike/%"
   1.361 +      S: * LIST () "/" "#Users/Mike/INBOX"
   1.362 +      S: * LIST () "/" "#Users/Mike/Foo"
   1.363 +      S: A003 OK LIST command completed.
   1.364 +
   1.365 +      A prefix string might not contain a hierarchy delimiter, because
   1.366 +      in some cases it is not needed as part of the prefix.
   1.367 +
   1.368 +      Example 5.9:
   1.369 +      ===========
   1.370 +
   1.371 +      < A server that allows access to the Other Users' Namespace by
   1.372 +      prefixing the others' mailboxes with a '~' followed by <username>,
   1.373 +      where <username> is a user name as per the IMAP4 LOGIN or
   1.374 +      AUTHENTICATE command.>
   1.375 +
   1.376 +      C: A001 NAMESPACE
   1.377 +      S: * NAMESPACE (("" "/")) (("~" "/")) NIL
   1.378 +      S: A001 OK NAMESPACE command completed
   1.379 +
   1.380 +      < List the mailboxes for user mark >
   1.381 +
   1.382 +      C: A002 LIST "" "~mark/%"
   1.383 +      S: * LIST () "/" "~mark/INBOX"
   1.384 +      S: * LIST () "/" "~mark/foo"
   1.385 +      S: A002 OK LIST command completed
   1.386 +
   1.387 +   Historical convention has been to start all namespaces with the "#"
   1.388 +   character.  Namespaces that include the "#" character are not IMAP
   1.389 +   URL [IMAP-URL] friendly requiring the "#" character to be represented
   1.390 +   as %23 when within URLs.  As such, server implementers MAY instead
   1.391 +   consider using namespace prefixes that do not contain the "#"
   1.392 +   character.
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Gahrns & Newman             Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.400 +
   1.401 +
   1.402 +6. Formal Syntax
   1.403 +
   1.404 +   The following syntax specification uses the augmented Backus-Naur
   1.405 +   Form (BNF) as described in [ABNF].
   1.406 +
   1.407 +   atom = <atom>
   1.408 +      ; <atom> as defined in [RFC-2060]
   1.409 +
   1.410 +   Namespace = nil / "(" 1*( "(" string SP  (<"> QUOTED_CHAR <"> /
   1.411 +      nil) *(Namespace_Response_Extension) ")" ) ")"
   1.412 +
   1.413 +   Namespace_Command = "NAMESPACE"
   1.414 +
   1.415 +   Namespace_Response_Extension = SP string SP "(" string *(SP string)
   1.416 +      ")"
   1.417 +
   1.418 +   Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
   1.419 +      Namespace
   1.420 +
   1.421 +      ; The first Namespace is the Personal Namespace(s)
   1.422 +      ; The second Namespace is the Other Users' Namespace(s)
   1.423 +      ; The third Namespace is the Shared Namespace(s)
   1.424 +
   1.425 +      nil = <nil>
   1.426 +         ; <nil> as defined in [RFC-2060]
   1.427 +
   1.428 +      QUOTED_CHAR = <QUOTED_CHAR>
   1.429 +         ; <QUOTED_CHAR> as defined in [RFC-2060]
   1.430 +
   1.431 +      string = <string>
   1.432 +         ; <string> as defined in [RFC-2060]
   1.433 +         ; Note that  the namespace prefix is to a mailbox and following
   1.434 +         ; IMAP4 convention, any international string in the NAMESPACE
   1.435 +         ; response MUST be of modified UTF-7 format as described in
   1.436 +         ;  [RFC-2060].
   1.437 +
   1.438 +7. Security Considerations
   1.439 +
   1.440 +   In response to a LIST command containing an argument of the Other
   1.441 +   Users' Namespace prefix, a server SHOULD NOT list users that have not
   1.442 +   granted list access to their personal mailboxes to the currently
   1.443 +   authenticated user.  Providing such a list, could compromise security
   1.444 +   by potentially disclosing confidential information of who is located
   1.445 +   on the server, or providing a starting point of a list of user
   1.446 +   accounts to attack.
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Gahrns & Newman             Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.456 +
   1.457 +
   1.458 +8. References
   1.459 +
   1.460 +   [RFC-2060], Crispin, M., "Internet Message Access Protocol Version
   1.461 +   4rev1", RFC 2060, December 1996.
   1.462 +
   1.463 +   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   1.464 +   Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.465 +
   1.466 +   [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
   1.467 +   Specifications: ABNF", RFC 2234, November 1997.
   1.468 +
   1.469 +   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
   1.470 +
   1.471 +9.  Acknowledgments
   1.472 +
   1.473 +   Many people have participated in the discussion of IMAP namespaces on
   1.474 +   the IMAP mailing list.  In particular, the authors would like to
   1.475 +   thank Mark Crispin for many of the concepts relating to the Personal
   1.476 +   Namespace and accessing the Personal Namespace of other users, Steve
   1.477 +   Hole for summarizing the two namespace models, John Myers and Jack De
   1.478 +   Winter for their work in a preceding effort trying to define a
   1.479 +   standardized personal namespace, and Larry Osterman for his review
   1.480 +   and collaboration on this document.
   1.481 +
   1.482 +11. Authors' Addresses
   1.483 +
   1.484 +   Mike Gahrns
   1.485 +   Microsoft
   1.486 +   One Microsoft Way
   1.487 +   Redmond, WA, 98072, USA
   1.488 +
   1.489 +   Phone: (425) 936-9833
   1.490 +   EMail: mikega@microsoft.com
   1.491 +
   1.492 +
   1.493 +   Chris Newman
   1.494 +   Innosoft International, Inc.
   1.495 +   1050 East Garvey Ave. South
   1.496 +   West Covina, CA, 91790, USA
   1.497 +
   1.498 +   EMail: chris.newman@innosoft.com
   1.499 +
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Gahrns & Newman             Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 2342                    IMAP4 Namespace                     May 1998
   1.512 +
   1.513 +
   1.514 +12.  Full Copyright Statement
   1.515 +
   1.516 +   Copyright (C) The Internet Society (1998).  All Rights Reserved.
   1.517 +
   1.518 +   This document and translations of it may be copied and furnished to
   1.519 +   others, and derivative works that comment on or otherwise explain it
   1.520 +   or assist in its implementation may be prepared, copied, published
   1.521 +   and distributed, in whole or in part, without restriction of any
   1.522 +   kind, provided that the above copyright notice and this paragraph are
   1.523 +   included on all such copies and derivative works.  However, this
   1.524 +   document itself may not be modified in any way, such as by removing
   1.525 +   the copyright notice or references to the Internet Society or other
   1.526 +   Internet organizations, except as needed for the purpose of
   1.527 +   developing Internet standards in which case the procedures for
   1.528 +   copyrights defined in the Internet Standards process must be
   1.529 +   followed, or as required to translate it into languages other than
   1.530 +   English.
   1.531 +
   1.532 +   The limited permissions granted above are perpetual and will not be
   1.533 +   revoked by the Internet Society or its successors or assigns.
   1.534 +
   1.535 +   This document and the information contained herein is provided on an
   1.536 +   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1.537 +   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   1.538 +   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   1.539 +   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1.540 +   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.541 +
   1.542 +
   1.543 +
   1.544 +
   1.545 +
   1.546 +
   1.547 +
   1.548 +
   1.549 +
   1.550 +
   1.551 +
   1.552 +
   1.553 +
   1.554 +
   1.555 +
   1.556 +
   1.557 +
   1.558 +
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Gahrns & Newman             Standards Track                    [Page 10]
   1.566 +