Network Working Group M. Rose Internet-Draft Invisible Worlds, Inc. Expires: October 30, 2001 G. Klyne Baltimore Technologies D. Crocker Brandenburg Consulting May 2001 The APEX Access Service draft-ietf-apex-access-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 30, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes the APEX access service, addressed as the well- known endpoint "apex=access". The access service is used to control use of both the APEX "relaying mesh" and other APEX services. Rose, et. al. Expires October 30, 2001 [Page 1] Internet-Draft The APEX Access Service May 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Access Information Entries . . . . . . . . . . . . . . . . . . 3 1.2 Access Information Services . . . . . . . . . . . . . . . . . 4 2. Querying Access Information . . . . . . . . . . . . . . . . . 6 3. Management of Access Information . . . . . . . . . . . . . . . 8 3.1 Retrieval of Access Information . . . . . . . . . . . . . . . 9 3.2 Update of Access Information . . . . . . . . . . . . . . . . . 10 4. Format of Access Entries . . . . . . . . . . . . . . . . . . . 13 5. The Access Service . . . . . . . . . . . . . . . . . . . . . . 16 5.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 17 5.2 The Query Operation . . . . . . . . . . . . . . . . . . . . . 19 5.3 The Get Operation . . . . . . . . . . . . . . . . . . . . . . 21 5.4 The Set Operation . . . . . . . . . . . . . . . . . . . . . . 22 5.5 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 24 6. Registration: The Access Service . . . . . . . . . . . . . . . 25 7. The Access Service DTD . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 B. Amendment history . . . . . . . . . . . . . . . . . . . . . . 32 B.1 Changes from draft-ietf-apex-access-03 . . . . . . . . . . . . 32 B.2 Changes from draft-ietf-apex-access-02 . . . . . . . . . . . . 32 B.3 Changes from draft-ietf-apex-access-01 . . . . . . . . . . . . 32 B.4 Changes from draft-ietf-apex-access-00 . . . . . . . . . . . . 32 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33 Rose, et. al. Expires October 30, 2001 [Page 2] Internet-Draft The APEX Access Service May 2001 1. Introduction This memo describes a access service that is built upon the APEX [1] "relaying mesh". The APEX access service is used to control use of both the relaying mesh and other APEX services. APEX, at its core, provides a best-effort datagram service. Within an administrative domain, all relays must be able to handle messages for any endpoint within that domain. APEX services are logically defined as endpoints but given their ubiquitous semantics they do not necessarily need to be associated with a single physical endpoint. As such, they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e., +----------+ +----------+ +----------+ +---------+ | APEX | | APEX | | APEX | | | | access | | presence | | report | | ... | | service | | service | | service | | | +----------+ +----------+ +----------+ +---------+ | | | | | | | | +----------------------------------------------------------------+ | | | APEX core | | | +----------------------------------------------------------------+ That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE). APEX applications communicate with the access service by exchanging data with the well-known endpoint "apex=access" in the corresponding administrative domain, e.g., "apex=access@example.com" is the endpoint associated with the access service in the "example.com" administrative domain. Note that within a single administrative domain, the relaying mesh makes use of the APEX access service in order to determine if an originator is allowed to transmit data to a recipient (c.f., Step 5.3 of Section 4.4.4.1 of [1]). 1.1 Access Information Entries Access information is organized around access entries, each of which is contains: o an owner: an APEX endpoint with which the entry is associated. Rose, et. al. Expires October 30, 2001 [Page 3] Internet-Draft The APEX Access Service May 2001 The destination endpoint of an APEX operation determines the owner of the access entry used to determine permission to perform the operation. o an actor: an APEX endpoint that is granted permission to perform some operation. o a list of actions: a list of operations that are permitted for the designated actor to perform with the owner endpoint. Each access entry is associated with an owner, which is some entity that determines access to some facilities accessed by APEX operations. An access permission owner is identified by an APEX endpoint address. The precise relationship between an APEX operation and the owner who determines access permissions is dependent on the particular operation being performed. For example: o when sending data to an APEX endpoint, it is the endpoint to which the data is addressed who determines the access permissions for the operation; o when retrieving access information, the request is sent to "apex=access@domain.com", but it is the owner named in the request that determines whether the operation is permitted; o when requesting presence information, it is the subject of presence information that determines whether or not the requested operation will be honoured. Thus, the content of a request must be understood in order for access permissions to be determined. This means that APEX services themselves must operate as access policy enforcement points, extracting relevant information from a request and passing it to the access service which operates as an access policy decision point. The access entry for a single owner may control access to a range of different APEX services that are performed on its behalf; e.g. data delivery, access control, presence. Note that there is no defined way to specify permission for message relaying, which is a matter for local provisioning within an administrative domain. 1.2 Access Information Services The access service supports two kinds of activity: o access query, used by an access policy enforcement point to Rose, et. al. Expires October 30, 2001 [Page 4] Internet-Draft The APEX Access Service May 2001 discover whether or not a requested operation is permitted, and o access information management, used by administration clients that need a standard way to retrieve and update specific access entries. Rose, et. al. Expires October 30, 2001 [Page 5] Internet-Draft The APEX Access Service May 2001 2. Querying Access Information When an application wants to discover about access associated with an endpoint, it sends a "query" element to the service, e.g., +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | | <--------- ok -- | | +-------+ +-------+ C: S: No wildcarding is allowed for the owner, actor or actions list in a operation. The service immediately responds with an allow or deny operation indicating whether the indicated access is allowed for the designated actor, and the same transaction-identifier, e.g., +-------+ +-------+ | | <------- data -- | | | relay | |access | | | -- ok ---------> | svc. | +-------+ +-------+ C: S: Rose, et. al. Expires October 30, 2001 [Page 6] Internet-Draft The APEX Access Service May 2001 or C: S: The response indicates that all of the requested actions are permitted for the designated actor. Note that access entries held by the access service may include limited wildcard values for the actor value. In determing the response to a query, the access service selects a single access entry that exactly matches the supplied owner, and that matches the supplied actor using the following selection priorities: 1. exact match (bill@example.com) 2. any service in specified domain (apex=*@example.com) 3. any endpoint in specified domain (*@example.com) 4. specified endpoint in any domain (bill@* or apex=presence@*) 5. any service in any domain (apex=*@*) 6. any endpoint in any domain (*@*) Rose, et. al. Expires October 30, 2001 [Page 7] Internet-Draft The APEX Access Service May 2001 3. Management of Access Information Management of access information falls into two categories: o applications may retrieve the access entry associated with an owner/actor endpoint combination; and, o applications may update (i.e. replace or delete) the access entry associated with an owner/actor endpoint combination. Note that for the purpose of retrieving and updating access entries, no special wildcard processing is performed. The actor value for an entry may contain limited wildcard characters which have special significance only when performing a query operation (see Section 2). For the purposes of retrieving and updating entries, actor values are treated simply as literal names. Rose, et. al. Expires October 30, 2001 [Page 8] Internet-Draft The APEX Access Service May 2001 3.1 Retrieval of Access Information When an application wants to retrieve the access entry associated with an owner/actor endpoint combination, it sends a "get" element to the service, e.g., +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | | <--------- ok -- | | +-------+ +-------+ C: S: The service immediately responds with a set operation containing the access entry and the same transaction-identifier, e.g., +-------+ +-------+ | | <------- data -- | | | relay | |access | | | -- ok ---------> | svc. | +-------+ +-------+ C: S: Rose, et. al. Expires October 30, 2001 [Page 9] Internet-Draft The APEX Access Service May 2001 3.2 Update of Access Information When an application wants to add or modify an access entry associated with an owner/actor endpoint combination, it sends a "set" element to the service containing the new access entry, e.g., +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | | <--------- ok -- | | +-------+ +-------+ C: S: The service immediately responds with a reply operation containing the same transaction-identifier, e.g., +-------+ +-------+ | | <------- data -- | | | relay | |access | | | -- ok ---------> | svc. | +-------+ +-------+ C: S: Note that Step 5 of Section 5.4 requires that the "lastUpdate" attribute of an access entry be supplied in order to update that entry; accordingly, applications must successfully retrieve an access Rose, et. al. Expires October 30, 2001 [Page 10] Internet-Draft The APEX Access Service May 2001 entry prior to trying to update that entry. The service also immediately sends a set operation to the endpoint associated with the access entry, e.g., +-------+ +-------+ | | <------- data -- | | | relay | |access | | | -- ok ---------> | svc. | +-------+ +-------+ C: S: Note that Step 6.2 of Section 5.4 requires that the access service update the "lastUpdate" attribute of an access entry when it is updated. Rose, et. al. Expires October 30, 2001 [Page 11] Internet-Draft The APEX Access Service May 2001 When an application wants to remove the access entry associated with an owner/actor endpoint combination, it sends a "set" element to the service specifying no value for the permitted actions, e.g., +-------+ +-------+ | | -- data -------> | | | appl. | | relay | | | <--------- ok -- | | +-------+ +-------+ C: S: The response to this is as described above for modifying an access entry, except that the notification sent to the associated owner endpoint does not contain a list of actions. Rose, et. al. Expires October 30, 2001 [Page 12] Internet-Draft The APEX Access Service May 2001 4. Format of Access Entries Each administrative domain is responsible for maintaining a list of "access entries" for each of its endpoints and every subaddress (regardless of whether those endpoints are currently attached to the relaying mesh). A separate access entry is required for each actor or group of actors for whom access permission is specified. Section 7 defines the syntax for access entries. Each access entry has the following attributes: o the "owner" attribute specifies the address (endpoint or subaddress) associated with the access entry; o the "actor" attribute designates an entity or group of entitites for whom access permissions are specified, as described below; o the "actions" attribute specifies permissions as service/operation pairs, (e.g., "presence:publish" refers to the "publish" operation of the "presence" service). To refer to all services and/or all operations, the reserved value "all" is used (e.g., "all:data", "presence:all", and so on). Note that the service specified as "core" is reserved for use by the relaying mesh, e.g., the "core:data" permission is consulted by the relaying mesh (c.f., Step 5.3 of Section 4.4.4.1 of [1]). o the "lastUpdate" attribute specifies the date and time that the service last updated the access entry; and, An actor is an APEX endpoint and is specified using the "entity" syntax specified in Section 2.2 of [1]. However, both the "local" and "domain" parts may contain limited wildcarding: o The "local" part is either: * a literal string (e.g., "fred"); or, * the value "apex=*", specifying all APEX services; or, * the value "*", specifying any endpoint other than an APEX service. o The "domain" part is either: * a FQDN (e.g., "example.com"); or, * the value "*", specifying all administrative domains. Rose, et. al. Expires October 30, 2001 [Page 13] Internet-Draft The APEX Access Service May 2001 In the absence of specific access entries to the contrary, the following default actor/action permissions are applied for each endpoint: actor='local@domain' actions='all:all' actor='apex=*@domain' actions='all:all' actor='apex=*@*' actions='core:data' actor='*@*' actions='' where "local@domain" specifies the endpoint associated with the access entry. Because of wildcarding in actor names, several access entries may be applicable for any given combination of endpoint and actor. When deciding the access entry to be used for determining permission for a request from an actor, more exact matches are preferred over looser matches; for details, see Section 2. For example, consider the following access entries: owner='fred@example.com' .. actor='wilma@example.com' actions='all:all' .. actor='mr.slate@example.com' actions='core:data' .. actor='*@example.com' actions='core:data presence:subscribe presence:watch' .. actor='*@*' actions='core:data' Briefly: o For endpoints within the "example.com" administrative domain: * "fred", "wilma", and all APEX services within the "example.com" administrative domain are allowed access to all operations for fred@example.com; * "mr.slate" is allowed access only to send data through the relaying mesh to fred@example.com; and, * any other endpoint within the "example.com" administrative domain is allowed access to send data and invoke the "subscribe" and "watch" operations of the APEX presence service with respect to fred@example.com. o For any endpoint outside the "example.com" administrative domain, the endpoint is allowed access to send data, regardless of whether Rose, et. al. Expires October 30, 2001 [Page 14] Internet-Draft The APEX Access Service May 2001 it is an APEX service. Note that although the four default entries are always available, the explicit entry for actor "*@*" overrides the corresponding default entry. As a second example, consider this access entry: This access entry, for a subaddress of "fred@example.com", allows only "barney/appl=wb@example.com" (the actor) to send data through the relaying mesh (the "core:data' action) to "fred/appl=wb@example.com" (the owner). Rose, et. al. Expires October 30, 2001 [Page 15] Internet-Draft The APEX Access Service May 2001 5. The Access Service Section 6 contains the APEX service registration for the access service: o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=access". o Section 7 defines the syntax of the operations exchanged with the service. o A consumer of the service initiates communications by sending data containing a query operation. o An admninistrator of the service initiates communications by sending data containing either the get or set operation. o The service replies to these operations, and does not initiate communications. o When an access entry is changed, the service sends a notification to the owner endpoint associated with the changed entry. An implementation of the service must maintain information about access entries in persistent storage. Consult Section 6.1.1 of [1] for a discussion on the properties of long-lived transaction-identifiers. Rose, et. al. Expires October 30, 2001 [Page 16] Internet-Draft The APEX Access Service May 2001 5.1 Use of XML and MIME Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a BEEP [2] payload. For example, to transmit: where "..." refers to: then the corresponding BEEP message might look like this: C: MSG 1 2 . 42 1234 C: Content-Type: multipart/related; boundary="boundary"; C: start="<1@example.com>"; C: type="application/beep+xml" C: C: --boundary C: Content-Type: application/beep+xml C: Content-ID: <1@example.com> C: C: C: C: C: C: --boundary C: Content-Type: application/beep+xml C: Content-ID: <2@example.com> C: C: C: --boundary-- C: END Rose, et. al. Expires October 30, 2001 [Page 17] Internet-Draft The APEX Access Service May 2001 or this: C: MSG 1 1 . 42 267 C: Content-Type: application/beep+xml C: C: C: C: C: C: C: C: C: END Rose, et. al. Expires October 30, 2001 [Page 18] Internet-Draft The APEX Access Service May 2001 5.2 The Query Operation When an application wants to discover about access permissions associated with an endpoint address, it sends a "query" element to the service. The "query" element has "owner", "actor", "actions" and "transID" attributes, and no content: o the "owner" attribute specifies the owner endpoint address associated with the access entry; o the "actor" attribute specifies the endpoint address for which access permissions are to be queried; o the "actions" attribute specifies one or more actions for which permission is to be determined; and o the "transID" attribute specifies the transaction-identifier associated with this operation. When the service receives a "query" element, we refer to the "owner" attribute of that element as the "subject". The service performs these steps: 1. If the subject is outside this administrative domain, a "reply" element having code 553 is sent to the originator. 2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator. 3. If the subject's access entry matching the originator address (see Section 2) does not contain an "access:query" token, or corresponding permission, a "reply" element having code 537 is sent to the originator. 4. Otherwise, the subject's access entry matching the actor attribute of the query element is selected (see Section 2) and compared with the actions attribute from the query element: * if all of the permissions in the query element are contained in the access entry then an "allow" element is sent to the originator. * if any of the requested permissions is not present in the access entry, a "deny" element is sent to the originator. Regardless of whether an "allow", "deny" or "reply" element is sent Rose, et. al. Expires October 30, 2001 [Page 19] Internet-Draft The APEX Access Service May 2001 to the originator, the "transID" attribute is identical to the value found in the "query" element sent by the originator. Rose, et. al. Expires October 30, 2001 [Page 20] Internet-Draft The APEX Access Service May 2001 5.3 The Get Operation When an application wants to retrieve the access entry associated with an owner/actor endpoint combination, it sends a "get" element to the service. The "get" element has an "owner", "actor" and "transID" attributes, and no content: o the "owner" attribute specifies the address associated with the access entry; o the "actor" attribute specifies the address (with possible limited wilcarding) of an endpoint for which access permissions are retrieved; and o the "transID" attribute specifies the transaction-identifier associated with this operation. When the service receives a "get" element, we refer to the "owner" attribute as the "subject". The service performs these steps: 1. If the subject is outside this administrative domain, a "reply" element having code 553 is sent to the originator. 2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator. 3. If the subject's access entry for the originator does not contain a "access:get" token or equivalent permission, a "reply" element having code 537 is sent to the originator. 4. If the subject has an access entry for the specified actor a "set" element corresponding to that entry is sent to the originator. 5. Otherwise, a "set" element containing the supplied "owner" and "actor" attributes, but containing no "actions" or "lastUpdate" attributes, is sent to the originator. Regardless of whether a "set" or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "get" element sent by the originator. Rose, et. al. Expires October 30, 2001 [Page 21] Internet-Draft The APEX Access Service May 2001 5.4 The Set Operation When an application wants to modify (i.e. remove or replace) the access entry associated with an owner/actor endpoint combination, it sends a "set" element to the service. The "set" element has a "transID" attribute, a "timeStamp" attribute, and contains an "access" element: o the "transID" attribute specifies the transaction-identifier associated with this operation; o the "timeStamp" attribute specifies the application's notion of the current date and time; and, o the "access" element contains the access entry to be added, replaced or removed. The "access" element has "owner", "actor", optional "actions" and optional "lastUpdate" attributes, and no content: o the "owner" attribute specifies the owner endpoint address associated with the access entry; o the "actor" attribute specifies the endpoint address (with possible limited wilcarding) for which access permissions are specified; o the "actions" attribute specifies one or more actions for which permission is to be determined. This attribute is present to add or replace an access entry, or omitted to remove an existing entry; and o the "lastUpdate" attribute, if present, specifies the timestamp of a current access entry that is to be replaced. Rose, et. al. Expires October 30, 2001 [Page 22] Internet-Draft The APEX Access Service May 2001 When the service receives a "set" element, we refer to the "owner" attribute of the access element as the "subject". The service performs these steps: 1. If the subject is outside this administrative domain, a "reply" element having code 553 is sent to the originator. 2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator. 3. If the subject's access entry for the originator endpoint does not contain an "access:set" token or equivalent permission, a "reply" element having code 537 is sent to the originator. 4. If there exists an access entry for the specified owner/actor combination, and the "lastUpdate" attribute of the supplied "access" element is not present or not identical to the "lastUpdate" attribute of the existing entry, a "reply" element having code 555 is sent to the originator. (This allows for a get-modify-set sequence to perform atomic updates.) 5. If there exists no access entry for the specified owner/actor combination, and the "lastUpdate" attribute is present in the supplied "access" element, a "reply" element having code 555 is sent to the originator. 6. If the supplied "access" element contains no "actions" attribute then any existing access entry held by the service is deleted, 7. Otherwise: 1. The access entry for the indicated owner/actor combination is updated from the supplied "access" element. 2. The "lastUpdate" attribute of the updated access entry is set to the service's notion of the current date and time (which should be different from the "lastUpdate" value associated with any replaced entry). 3. A "reply" element having code 250 is sent to the originator. 4. A "set" element corresponding to the new access entry is sent to the subject endpoint. When sending the "reply" element, the "transID" attribute is identical to the value found in the "set" element sent by the originator. Rose, et. al. Expires October 30, 2001 [Page 23] Internet-Draft The APEX Access Service May 2001 5.5 The Reply Operation While processing operations, the service may respond with a "reply" element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for the syntax and semantics of the reply operation. Rose, et. al. Expires October 30, 2001 [Page 24] Internet-Draft The APEX Access Service May 2001 6. Registration: The Access Service Well-Known Endpoint: apex=access Syntax of Messages Exchanged: c.f., Section 7 Sequence of Messages Exchanged: c.f., Section 5 Access Control Tokens: access:query, access:get, access:set Contact Information: c.f., the "Authors' Addresses" section of this memo Rose, et. al. Expires October 30, 2001 [Page 25] Internet-Draft The APEX Access Service May 2001 7. The Access Service DTD %APEXCORE; Rose, et. al. Expires October 30, 2001 [Page 28] Internet-Draft The APEX Access Service May 2001 8. Security Considerations Consult [1]'s Section 11 for a discussion of security issues. Rose, et. al. Expires October 30, 2001 [Page 29] Internet-Draft The APEX Access Service May 2001 References [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange Core", draft-ietf-apex-core-02 (work in progress), May 2001. [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. Authors' Addresses Marshall T. Rose Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: mrose@invisible.net URI: http://invisible.net/ Graham Klyne Baltimore Technologies 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK Phone: +44 118 903 8000 EMail: gk@acm.org David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale, CA 94086 US Phone: +1 408 246 8253 EMail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/ Rose, et. al. Expires October 30, 2001 [Page 30] Internet-Draft The APEX Access Service May 2001 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Neil Cook, Darren New, Chris Newman, and Scott Pead. Rose, et. al. Expires October 30, 2001 [Page 31] Internet-Draft The APEX Access Service May 2001 Appendix B. Amendment history B.1 Changes from draft-ietf-apex-access-03 o Change access service to use an owner/actor entry as its fundamental unit of access information. o Separate access query function from access information management functions. o Remove redundant "owner" attribute from "set" element. o Merge "access" and "entry" elements into just "access". Multiple "access" elements are now needed for a single subject. o Change framework for applying defaults: default entries are applied in the absence of any overriding access entry. o Add some introductory text about the relationship between access permision owners and APEX operations. B.2 Changes from draft-ietf-apex-access-02 o A small number of typos were corrected. B.3 Changes from draft-ietf-apex-access-01 o It is made more clear that each subaddress has its own access entry. o A successful set operation results in the new access entry being sent to the endpoint associated with the entry. o A small number of typos were corrected. B.4 Changes from draft-ietf-apex-access-00 o Change "addr-spec" syntax from RFC 822 to APEX's custom ABNF. Rose, et. al. Expires October 30, 2001 [Page 32] Internet-Draft The APEX Access Service May 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rose, et. al. Expires October 30, 2001 [Page 33]