INTERNET-DRAFT H. Sugano Expires: December, 2000 A. Iwakawa K. Otani T. Ohno S. Fujimoto Fujitsu June 2000 Privacy-enhanced Presence Protocol (PePP) 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a protocol designed for scalable and secure Instant Messaging and Presence Services. The protocol, Privacy enhanced Presence Protocol (PePP), has been developed for an experimental Presence Service and recently extended to satisfy a variety of requirements for the Internet-wide, interoperable standards. This is a protocol proposal for the IMPP Working Group. Sugano et al. [Page 1] INTERNET DRAFT PePP Specification April 2000 Table of Contents 1. Introduction ......................................... 4 2. Terminology .......................................... 4 3. Protocol Overview .................................... 6 3.1. Architecture ......................................... 6 3.2. Model for Presence Service ........................... 7 3.2.1. Privacy Requirements ................................. 7 3.2.2. Presence Sections .................................... 7 3.2.3. Section based Access Control ......................... 8 3.2.4. Lease Model of Presence Information .................. 9 3.2.5. Two Modes of Subscription ............................ 10 3.3. PePP Connections ..................................... 10 3.3.1. Client Connections ................................... 11 3.3.2. Server Connections ................................... 13 3.3.3. Direct Connections ................................... 15 3.4. Subscription Model ................................... 16 3.4.1. Behavior of Clients .................................. 17 3.4.2. Behavior of Home Servers ............................. 17 3.4.3. Behavior of Target Servers ........................... 18 3.5. Instant Messaging Service ............................ 18 3.5.1. Basic Architecture ................................... 18 3.5.2. IM Conversation ...................................... 19 3.5.3. Multiparty Conversation .............................. 19 3.6. Character and Content Encoding ....................... 20 4. Considerations Regarding IMPP Requirements ........... 20 4.1. Scalability .......................................... 21 4.2. Security ............................................. 21 4.3. Wireless ............................................. 23 4.4. Separability of Services ............................. 23 5. PePP Messages ........................................ 24 5.1. Message Overview ..................................... 24 5.2. PePP Addresses ....................................... 25 5.3. Message Syntax ....................................... 25 6. PePP Headers ......................................... 27 6.1. From ................................................. 27 6.2. Connection-Mode ...................................... 27 6.3. Max-Content-Length ................................... 27 6.4. Subscription-Mode .................................... 28 6.5. Subscription-ID ...................................... 28 6.6. Regarding ............................................ 28 6.7. Change-Mode .......................................... 29 6.8. Cancel-Type .......................................... 29 6.9. Duration ............................................. 30 6.10. Last-Modified ....................................... 30 6.11. Section-ID .......................................... 31 6.12. Section-Name ........................................ 31 6.13. Location ............................................ 31 Sugano et al. [Page 2] INTERNET DRAFT PePP Specification April 2000 6.14. Content-Type ........................................ 32 6.15. Content-Length ...................................... 32 6.16. Auth-State .......................................... 32 6.17. SASL-Mechanism ...................................... 32 6.18. Message-ID .......................................... 32 6.19. Conversation-ID ..................................... 33 7. PePP Methods ......................................... 33 7.1. LOGIN ................................................ 33 7.2. LOGOUT ............................................... 34 7.3. SUBSCRIBE ............................................ 35 7.4. UNSUBSCRIBE .......................................... 36 7.5. REQUESTNOTIFY ........................................ 37 7.6. CHANGE ............................................... 38 7.7. CANCEL ............................................... 39 7.8. FETCH ................................................ 40 7.9. NOTIFY ............................................... 41 7.10. PULL ................................................ 42 7.11. SEND ................................................ 42 7.12. RECEIVE ............................................. 43 7.13. CALLBACK ............................................ 44 7.14. REDIRECT ............................................ 45 7.15. SETACL .............................................. 45 7.16. GETACL .............................................. 46 7.17. CREATESECTION ....................................... 46 7.18. DELETESECTION ....................................... 47 7.19. PING ................................................ 47 7.20. STARTTLS ............................................ 48 7.21. CONNECT ............................................. 49 8. Status Codes ......................................... 49 8.1. 1xx .................................................. 50 8.2. 2xx .................................................. 50 8.3. 3xx .................................................. 50 8.4. 4xx .................................................. 51 8.5. 5xx .................................................. 52 9. Presence Information Data Format ..................... 53 9.1. Overview ............................................. 53 9.2. Tag Descriptions ..................................... 54 10. Subscribers Information ............................. 57 11. Access Control List ................................. 58 11.1. Overview ............................................ 58 11.2. ACL Functions ....................................... 58 11.3. Syntax of ACL ....................................... 59 12. Sample Transcripts .................................. 61 13. Security Considerations ............................. 65 14. Acknowledgments ..................................... 65 15. References .......................................... 65 16. Authors' Addresses .................................. 66 Sugano et al. [Page 3] INTERNET DRAFT PePP Specification April 2000 1. Introduction Instant Messaging (IM) and Presence Information (PI) Services have received broad attention as an emerging technology for real-time communication on the Internet. While there are a couple of services already deployed and widely used, each of those is based on its proprietary protocol and users cannot make use of IM Services like e-mails. This is a serious problem to overcome from both the technical and industrial standpoints. To solve the problem, the Instant Messaging and Presence Protocol (IMPP) WG has been formed at IETF, and been working to create an open, interoperable standards for IM/Presence technologies. We at Fujitsu have long been interested in the development of the Internet-wide standards for IM and Presence services. To this end, we have collaborated with other players and contributed to the design of the standards. At the same time, we have been working on an Instant Messaging/Presence protocol called PePP for experimental client and server development. PePP is still a work in progress, and the current implementation is mainly concerned with the single domain utilization. Thus, we have been working to improve PePP to make it satisfy the IMPP requirements [Reqts] based on our interest for the interoperable standard. Our main concerns in the development of PePP are security/privacy and scalability. In particular, as the Presence Service is considered to be fairly privacy sensitive, PePP is designed to have a means for fine privacy control on publishing a variety of Presence Information. For scalability, PePP has some features to avoid the server and connection bottlenecks. This document describes the present version of the extended PePP specification. The authors submits this document as a proposal for the IMPP standardization. Further, we wish to share our ideas in the PePP design with the community to spur further discussion of the development of the standard. We would welcome any comments, suggestions and evaluations on PePP. 2. Terminology This document makes use of the vocabulary defined in the IMPP Model and Requirements documents [Model,Reqts]. The capitalized terms such as PRESENTITY, WATCHER, PRESENCE SERVICE are used in the same meaning as defined in [Model,Reqts] unless otherwise stated. Some newly introduced terms are also defined here. Sugano et al. [Page 4] INTERNET DRAFT PePP Specification April 2000 A "PePP Server", or just a server is a logical entity which provides the PePP IM/Presence services. A "PePP Client", or just a client is a logical entity which exchanges IMs and/or Presence Information interacting with the servers. Note that, although the IMPP Model document defines several types of ideal clients such as PRESENTITY, WATCHER, SENDER, and INBOX, the PePP client is an entity which may integrate these functions. A "Domain" in the context of PePP is an administrative entity of the IM/Presence services. A user of the IM/Presence services in PePP has an account in a domain, and the user can get the services using one or more clients to connect to the servers in the domain. We call the domain in which a user has an account the "Home Domain" of the user. For a user or the user's client, the "Home Server" is a server in the user's home domain which maintains and publishes Presence Information of the user. As stated in Section 3, the client only has a direct connection with the Home Server, and the user controls her/his Presence Information using the client. A "Resource" in the context of PePP is a data unit in the PePP server, at which Presence Information of a particular PRESENTITY is published so that WATCHERS could access it. Thus, a resource is a unit for controlling and publishing Presence Information. Each resource is managed by the user controlling the PRESENTITY whose Presence Information is published at the resource. The user is called the "Owner" of the resource. A "PePP Address" is an identifier to locate the PePP resource, which is represented by a URI. This is defined in Section 5. If a client tries to access the Presence Information of another user, the user's Home Server is sometimes called the "Target Server" from the viewpoint of the client. A "PePP message" or just a "Message" is the unit of PePP communication, consisting of a structured sequence of octets matching the syntax defined in Section 5. As defined there, a message is a "Request" message or a "Response" message. A "Message Body" is a part of a "Message" as defined in the same definition. Note that a "PePP message" has a different meaning from that of messages when we talk about "Instant Messages". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . Sugano et al. [Page 5] INTERNET DRAFT PePP Specification April 2000 3. Protocol Overview 3.1. Architecture PePP is designed for scalable and secure Instant Messaging and Presence (IM/P) Services. Because IM/P Services is usually provided as an integrated service, we have designed PePP as a single protocol for both services. The PePP architecture involves two kinds of components; clients and servers. Clients may serve as user agents to the IM/P services, but may also be other software entity to utilize the services. Servers may or may not be different for IM and Presence services, but we assume in this document that a single "Home Server" provides both service for a user. PePP adopts a Client-Server-Server-Client architecture. This means that a client only communicates with its home servers, and only servers can communicate with other servers which are possibly located in different domains. All messages exchanged between a client and a server and between a server and another server are transferred through TCP connections called "PePP connections". A PePP connection has two basic modes; the Client mode and Server mode. The Client mode is for a PePP connection between a client and a server, and the Server mode is for between servers. For descriptive simplicity, we use the terms "PePP Client Connections" and "PePP Server Connections" for PePP connections in the Client and Server mode, respectively. Fig.1 roughly depicts this architecture. PePP Server PePP Server +--------+ +--------+ | HS1 |------------------->| HS2 | | |<-------------------| | +--------+ PePP Server +--------+ ^ ^ ^ CONNECTIONS ^ ^ ^ | | | | | | PePP Client | | | | | | PePP Client CONNECTIONS | | | | | | CONNECTIONS | | | | | | v v v v v v +-----+ +----+ +-----+ +----+ | C1 | | C2 | | C3 | | C4 | +-----+ +----+ +-----+ +----+ PePP Clients PePP Clients Fig.1: PePP Architecture Sugano et al. [Page 6] INTERNET DRAFT PePP Specification April 2000 We assume that all the server/server relations could be fully trusted once they are authenticated each other based on appropriate authentication schemes. Thus, when a user in a different domain tries to access your Presence Information, you assume the user is already autheticated by her home domain and trust her identity. Furthermore, as we assume all the notification messages from other servers come through already established PePP Client Connections, the client can trust the authenticity of the notifications without extra authentication. 3.2. Model for Presence Service PePP provides a means of fine privacy control of Presence Information publication. 3.2.1. Privacy Requirements The IMPP Requirements document [Reqts] stipulates a variety of privacy requirements which IM/Presence services must meet. In addition to "confidentiality" as the most basic requirement, it states that a means for controlling privacy is necessary based on the observation that users are inclined to hide their activities from the public, and further they sometimes want to block a particular user from subscribing to their activity without letting the subscriber know their intention. This is a requirement for so-called "Polite Blocking" (5.1.15 [Reqts]). Another requirement for the Presence Service is that users want to show themselves differently to different watchers (5.2.3 [Reqts]), which is considered as a variation on "Polite Blocking". We call this a requirement for "Personae". These requirements lead our design practice to have multiple pieces of presence information that can be selectively shown to different subscribers. 3.2.2. Presence Sections The PePP model considers Presence Information contained in a PePP resource as a collection of several pieces, each of which is called a "presence section". A presence section may contain a status information of a communication means, that of the user, or any other. A presence section can be considered as an embodiment of the notion of a PRESENCE TUPLE, which is defined by the Model document [Model]. Sugano et al. [Page 7] INTERNET DRAFT PePP Specification April 2000 The notion of presence sections is intended to be a unit for individual control of publication and filtering. For publication control, PePP allows the user controlling a PRESENTITY to set an access control list per section. For filtering control, PePP allows a WATCHER trying to subscribe to a PePP resource is capable of selecting presence sections to be notified their presence change. Considering the privacy requirements such as "Polite Blocking" and "Personae", there may be a case such that the user controlling a PRESENTITY wants to hide completely which presence sections are shown to the WATCHERS. To realize this in PePP, each presence section has a "section name" as an identifier for the WATCHERS in addition to its unique identifier "section ID". The section ID is used to manipulate the content or control information of the presence section and it is not shown to WATCHERS. Instead, a section name is shown to WATCHERS. An example of a structure of Presence Information (PI) in a PePP resource is shown in Fig.2. Here, an entire PI consists of several sections and each section contains a section ID, a section name, status, note, and an optional communication address. The syntax given here is temporary and the actual syntax of PI is defined in Section 9. +---- section(ID:xxx1, name:user-status) | +--- status(busy) | +--- note("Don't Call until 18:00pm.") | +---- section(ID:xxx2, name:user-status) | +--- status(available) | +--- note() | PI--+---- section(ID:xxx3, name:IM) | +--- status(idle) | +--- address(pepp://pepp.fujitsu.com/suga/iibox) | . +--- note:("Meeting.") | . | . | +---- section(ID:xxxZ, name:email) +--- status(available) +--- address(mailto:suga@sub.fujitsu.com) +--- note:() Fig.2: Presence Information as a set of Presence Sections 3.2.3. Section based Access Control Sugano et al. [Page 8] INTERNET DRAFT PePP Specification April 2000 Access control in the Presence Service typically controls how to treat requests from WATCHERS. As stated above, PePP assumes the Presence Information consists of multiple presence sections, and each presence section can have different access control list (ACL). When a request for subscription to a resource is received, the presence server evaluates the ACL of the resource to determine which sections should be shown to the WATCHER. Because several sections MAY have the same section name, this mechanism can be used for implementing a feature of "Personae". In the example of Fig.2, the sections "xxx1" and "xxx2" have the same section name "user-status". Consider these sections have ACLs such that the section "xxx1" accepts user A but denies user B, and the section "xxx2" accepts user B but denies user A. When a user A and user B try to subscribe to this resource, user A receives the section "xxx1" as "user-status" and user B receives the section "xxx2" with the same name. A WATCHER may receive several sections with the same name according to the ACCESS RULE, and we do not eliminate this situation in the protocol level. Individual implementation MAY select one of those sections with the same name. Note that ACLs for the requests other than that for subscription is not set for a section, but for a resource. 3.2.4. Lease Model of Presence Information PePP adopts the lease model for changing presence information. That is, a PRESENTITY MAY have two pieces of presence information, a lease value and a permanent value, for each section of the presence information. The lease value is associated with its duration value and the client renews the lease value within the duration to keep the lease. Otherwise, the value of the presence section turns back to the permanent value. This feature is preferable because it provides a general solution to handle presence status or availability of various kind of communication means. While availability of some communication means such as IM is subject to unexpected failure or constantly changing communication environment, that of other communication means might always be acquirable from a particular entity. The latter does not have to use the lease value and just change the permanent value of the presence section. The lease model gives flexibility to the control of presence information. Sugano et al. [Page 9] INTERNET DRAFT PePP Specification April 2000 3.2.5. Two Modes of Subscription In the case a WATCHER subscribes to a resource publishing Presence Information of a PRESENTITY, the WATCHER usually requires a change notification when the Presence Information is modified. However, a WATCHER sometimes prefers to fetch the Presence Information rather than being notified every time. As PePP has a section based feature of controlling Presence Information, it also provides WATCHERS with a means to choose whether or not to receive notifications for each section. In PePP, a subscriber can receive permitted presence sections within a single subscription to a resource. Moreover, within the subscription, the subscriber can restrict the sections to be notified change notifications. The selected sections are said to be in the Notify mode and the other ones are in the Pull mode. If all the sections are in the Notify mode, the subscription is the one in a usual sense and is called a Notify mode subscription. In a Pull mode, the client fetches the interested presence section when it wants. It is desirable when the subscriber wants to reduce the frequency of notification, for instance, in the case the user has a PePP client on a cellular phone device which charges per packet. This feature of PePP also realizes so called Selective Subscription. The subscriber in the Pull mode subscription can be considered as a notion of FETCHER defined by the IMPP Model document [Model]. Therefore, the notion of subscribers in PePP coincides that of WATCHERS of the Model document, and the Subscribers Information (see Section 10) corresponds to the WATCHER INFORMATION in it. This is so designed because we believe that a WATCHER should be required to declare the interest on the PRESENTITY whether she/he wants to get notifications or not. The Pull mode subscription may possibly cause a heavy load on the server. So, the server SHOULD be able to disallow it based on its policy. 3.3. PePP Connections All PePP connections are TCP connections. We adopted TCP because it is widely used as a reliable transport on the Internet and we believe all the messages in PePP, not only IMs but also changes and notifications of Presence Information, must be safely transported. It is also favorable in the existence of firewalls because UDP datagrams are not usually permitted to come into through firewalls. As stated above, PePP mandates two kinds of connections; PePP client Sugano et al. [Page 10] INTERNET DRAFT PePP Specification April 2000 connections and PePP server connections. Moreover, as an OPTIONAL specification, we propose a mechanism to establish a virtually direct connection between clients for the sake of the end-to-end security. 3.3.1. Client Connections A PePP client connection is a TCP connection between a client and its Home Server (HS). It is established only by the requests from clients. Clients can create more than one PePP connections if necessary. However, the first connection between the client and server plays a designated role as a "main" connection, and it is expected to be persistent during the service. Other connections are called "backup" connections. (a) Establishing a Connection On establishing a PePP client connection, a client opens a TCP connection to its HS and issues a LOGIN request message to the HS to start an authentication process. In the LOGIN request, the client MUST specify information about the authentication process (AUTH-STATE header), a connection mode (CONNECTION-MODE header), and MAY specify the maximum size of a message body it wishes to receive (MAX- CONTENT-LENGTH header). The client MUST specify "client" as the value of the Connection-Mode header field. PePP connections use SASL [SASL] as an authentication framework. The client and server negotiate the SASL Mechanism to be used by the SASL-Mechanism header field. SASL Mechanisms supported in the PePP LOGIN process are CRAM-MD5 [CRAM-MD5], EXTERNAL [SASL], and PLAIN [SASL-PLAIN]. 1) CRAM-MD5 - It can always be specified. 2) EXTERNAL - It uses TLS client authentication, and can be specified only if TLS client authentication is supported [TLS]. 3) PLAIN - It can be specified only if TLS encryption is enabled. The authentication process MAY be completed in a sequence of LOGIN requests and their responses. If the process terminated successfully, the last response MUST contain the fields specifying the connection ID (CONNECTION-ID header) and the MAX-CONTENT-LENGTH header field. The server MAY overwrite the value of the MAX-CONTENT-LENGTH specified by the client. If a client wishes a secure transport, it MAY issue a STARTTLS request prior to the LOGIN request in order to upgrade the established TCP connection to a TLS enabled secure one. The TLS layer simply encrypts the whole PePP messages on the top of a TCP Sugano et al. [Page 11] INTERNET DRAFT PePP Specification April 2000 connection, and provides secure communication channels between connection peers. (b) PePP Messages Once the PePP connection is established, it is used to send PePP request and response messages, which have similar syntax to HTTP messages, for the Presence and IM services. Like HTTP, a PePP request message generates a corresponding single response message. However, unlike HTTP, the PePP client connection can be used by both of the client and server to send the PePP request messages in both directions. Because the "main" client connection is supposed to be persistent, either ends of the connection MUST send PING requests periodically in order to confirm the other is alive. A PePP connection allows request pipelining, i.e. a client can send another request to the same connection before receiving the response to the previous request. Moreover, PePP allows the responses can be received in the different order from that of requests in order to avoid the server bottleneck caused by the processing overhead. To this end, every PePP messages MUST contain a Request-ID which is a unique identifier of each request message. The response message MUST contain the same Request-ID as that of the corresnponding request message to make correspondence between requests and responses. In order to distinguish a PePP message from the subsequent ones, a PePP message MAY contain a Content-Length header field. If a PePP message has a Content-Length header, its value MUST match the exact data size of the message body. In the client connections, all the PePP requests defined in this document can be issued. (c) Closing a Connection In order to close a PePP connection, a LOGOUT request MAY be sent by either ends of the connection. When a client or server receives a LOGOUT request, it MUST send 200 OK response if it is not to send another request to the connection peer. A client or server which has issued a LOGOUT request SHOULD wait an OK response before closing the connection. A client or server MAY close the connection without issuing a LOGOUT request in the case it encounters an abnormal status. For instance, Sugano et al. [Page 12] INTERNET DRAFT PePP Specification April 2000 the connection MAY be closed without any notice in the following cases. 1) The message border in the connection is broken because of a wrong Content-Length specified. 2) The size of the data currently receiving has exceeded the Max-Content-Length of the connection. 3) Time-out. (d) Backup Connections A client MAY request to establish more than one connections as "backups" if necessary. A backup connection is established by the same procedure as the main connection. It is typically considered necessary when the client is to send or receive data larger than the Max-Content-Length value of the main connection. The purpose of backup connections is to avoid latency caused by sending huge data through relatively slow connections. A client MUST request to establish a backup connection when it is to send a larger message body than the Max-Content-Length values of existing connections. If the data size is less than one of the Max- Content-Length values of the existing connections, the client SHOULD NOT request a new connection. A LOGIN request for a backup connection MUST have a Backup-For header field specifying the connection ID of the main connection. Although a server cannot request to open a new client connection, the server can issue a CALLBACK request through the main connection to ask the client to open a new connection. The CALLBACK request MAY contain information of the new address to be connected. If the server sends a message with a content larger than the Max-Content- Length values of existing connections, it MUST send a CALLBACK request to the main connection and wait for a new connection. The client MAY refuse the CALLBACK request. Backup connections MAY be closed by either end of the connection if it is considered no more necessary. Backup connection SHOULD be closed by LOGOUT requests. 3.3.2. Server Connections A PePP connection in the "server" mode, or a PePP server connection, is a TCP connection between servers. We use a term "Target Server" in contrast with "Home Server" to designate the remote server which the client cannot connect directly. Sugano et al. [Page 13] INTERNET DRAFT PePP Specification April 2000 If the Home Server of a client receives requests destined for another Target Server, it MUST establish a PePP server connection with the Target Server and forward the request to it. Unlike PePP client connections, only the initiator of the connection can issue requests in general and it MAY close the connection if it is judged not to be necessary any more. (a) Establishing a Connection When a server is to establish a PePP server connection, it MUST try to look up a DNS SRV record for the "impp" service on the "tcp" protocol prior to looking for an A record to locate another server. After locating the other server, the initiating server opens a TCP connection to the other and sends a LOGIN request to start authentication process. In the LOGIN request, the initiating server specifies information about the authentication process, a connection mode, and the maximum content size it wishes to receive. For the server connection, the value "server" MUST be specified as a value of Connection-Mode header field. The allowed SASL Mechanisms for PePP server connections are CRAM-MD5 [CRAM-MD5] and EXTERNAL [SASL]. PLAIN is disallowed because it seems unnecessary if the servers could authenticate each other by the TLS mutual authentication, and this is very likely. 1) EXTERNAL - It uses TLS client authentication, and can be specified only if TLS client authentication is supported. 2) CRAM-MD5 - It MAY be accepted depending on the server policy. CRAM-MD5 is only for an experimental use because sharing the secret passwords between different domains seems to be undesirable. It is STRONGLY RECOMMENDED to upgrading to a secure transport by issuing a STARTTLS request prior to the LOGIN request. (b) PePP Messages A PePP server connection is mainly used to exchange request and response messages between different domains. Unlike PePP client connections, server connections are one-way connections, i.e. only the initiating server of the connection can issue request messages except for a LOGOUT request. Like client connections, every PePP messages MUST contain a Request- ID which is a unique identifier of each request message, and every PePP messages MUST have a Content-Length header field whose value is the exact data size of its message-body. Sugano et al. [Page 14] INTERNET DRAFT PePP Specification April 2000 In the server connection, request messages for administration use is not allowed. Only the following request messages can be issued: LOGIN, LOGOUT, SUBSCRIBE, UNSUBSCRIBE, REQUESTNOTIFY, NOTIFY, PULL, SEND, PING, STARTTLS, CONNECT. (c) Closing a Connection Like PePP client connections, the either side of the connection MAY issue a LOGOUT request MAY to close it. When one of the connection peers receives a LOGOUT request, it MUST send '200 OK' response if it is not to send another request to the connection. The connection peer which has issued a LOGOUT request SHOULD wait an OK response before closing the connection. Same as the case of client connections, each connection peer MAY close the connection without issuing a LOGOUT request in some abnormal status. (d) Backup Connections A server MAY request to establish more than one connection to the same server at any time if necessary. So, a server MAY have one or more connections with the same Max-Content-Length value. As we may assume a PePP server can accept a LOGIN request from other servers, we do not distinguish "backup" connection from the "main" one. They are independent connections. 3.3.3. Direct Connections PePP has a mechanism to establish a virtually direct connection between clients. This is an OPTIONAL feature in PePP. A "Direct Connection" is a PePP Connection in the "direct" mode. The Direct Connection is the virtual connection between the clients and implemented using the Client Connection and the Server Connection. The Direct Connection is designed for providing the end-to-end security to PePP, especially a private conversation channel for IMs between clients in order not to be tampered by even the administrators of the servers. (a) Establishing a Connection Sugano et al. [Page 15] INTERNET DRAFT PePP Specification April 2000 When the client is going to establish to Direct Connection, first of all, the initiator client opens a new Client connection to its home server, and issues a LOGIN request to identify itself. Then, the initiator issues a CONNECT request, which asks the Home Server to provide a "raw" TCP socket over the current connection. The home server holds this TCP connection and opens another TCP connection to the Target Server. The way for discovering the Target Server is same as Server Connection described above. After LOGIN, the Home Server issues CONNECT request to ask "raw" TCP connection to the Target Server. Then, the Target Server issues a CALLBACK request to one of the 'receiver' clients which has asked IM delivery by the RECEIVE request (See Section 3.5). Having established a brand-new TCP connection with the client as a result of the CALLBACK request, the Target Server responds to the Home Server '200 OK' response, and the Home Server also responds '200 OK' response to the initiator client. Finally, the initiator client issues STARTTLS command, which is directly sent to the target client, and they can send and receive messages securely over this virtual connection. (b) PePP messages The Direct Connection behaves like as a Client Connection does, but only SEND, PING and LOGOUT requests are allowed. (c) Closing a Connection Both of the clients can issue a LOGOUT request to terminate the Direct Connection. The client which has issued a LOGOUT request SHOULD wait to receive the response. (d) Backup Connections Because the separate Direct Connections MAY be established between the same two clients, backup connections for the direct connection will not be necessary. 3.4. Subscription Model As stated in the previous sections, a PePP client MUST subscribe to Sugano et al. [Page 16] INTERNET DRAFT PePP Specification April 2000 Presence Information in the Target Server via its Home Server. The Home Server and Target Server are generally distinct servers while they might happen to coincide (Fig. 3). If a client has a subscription to a resource at a Target Server, the subscription information is stored at the client, its Home Server, and the Target Server. This subsection describes the behavior of these components in relation with Presence Information subscription. Client -------- Home Server (HS) -------- Target Server (TS) No Expiration Expiration Fig.3: Subscription Model 3.4.1. Behavior of Clients The PePP client connection is expected to be persistent until the client sends LOGOUT to the HS or some failure occurs. If the connection is in an abnormal status, for instance the response of PING request cannot be received, the client SHOULD disconnect the connection and try to reconnect in a certain amount of time and reissue all the SUBSCRIBE requests. 3.4.2. Behavior of Home Servers Because a PePP server connection is not necessarily persistent, the servers on the connection peers cannot detect another one's failure by watching the connection. As a solution to this problem, PePP utilizes the expiration model for subscription. Thus, a subscription will expire unless it is renewed by another subscription request within a certain amount of the associated duration time. A Home Server MUST store and manage all the subscription information of its clients possibly to the other servers. More precisely, a HS MUST watch all the requests from the clients to subscribe or unsubscribe resources and all the cancel notification from the TSs, and store the up-to-date information about each subscription, which consists of the target resource, subscription ID, duration, and the client connection ID. Moreover, in order to save the traffic on the client connections, the HS MUST renew all its clients' subscriptions regularly on behalf of the clients. If the HS detects a client connection has been lost, it MUST send requests to Target Servers to unsubscribe all the current subscriptions from the relevant client. Sugano et al. [Page 17] INTERNET DRAFT PePP Specification April 2000 The duration for subscription should be considerably long in order to reduce the traffic of renew messages. 3.4.3. Behavior of Target Servers The Target Servers MUST keep and manage the current subscription information in order to issue change notifications about the target resources. Because subscriptions are subject to expiration as stated above, a server SHOULD remove the subscription information unless it is renewed within a certain amount of duration time. When the TS detects an error of the notification requests it has issued, the subscription information which caused the failed notification MUST be removed. When the server removes some subscription information, it MUST send a notification to the relevant subscriber asking her/him to retry subscription. 3.5. Instant Messaging Service 3.5.1. Basic Architecture As PePP was originally developed for the Presence Service which requires minute control of presence publication, its basic Instant Messaging (IM) feature is designed similar to PePP's subscription and notification mechanism. A user's INSTANT INBOX in PePP is a PePP resource to be addressed when an IM is sent to the user. The receiver's client issues a RECEIVE request to the INBOX resource to register itself as a destination to forward the IMs it receives. Then the client connection is registered as a 'receiver' connection. An IM is delivered by SEND requests. When the INSTANT INBOX receives an IM, the server issues a new SEND request to forward the IM to the 'receiver' connection (see Fig.4). In PePP, the INBOX address of a receiver is not uniquely determined by her/his PePP address. Actually, the INBOX address may be same as the receiver's PePP address and may be different. Thus, the INBOX address MUST be contained in the user's presence information. The PePP client SHOULD send IMs for this address in order to be received by the intended recipient unless other address has been specified in an out-of-band manner. Sugano et al. [Page 18] INTERNET DRAFT PePP Specification April 2000 PePP Server PePP Server +---------+ +-------+ |SENDER HS|------------------>| INBOX | +---------+ SEND +-------+ ^ ^ | | | | |SEND RECEIVE| |SEND | | | | | v +---------+ +--------+ |SENDER UA| |INBOX UA| +---------+ +--------+ Sender Receiver Fig.4: Basic Architecture of PePP IM Service 3.5.2. IM Conversation Although an IM can be used as a single one-way message, the typical usage in the IM Service is a conversational one, i.e. two or more users exchange IMs in a 'chat' style. When a user wants to talk with a buddy, she directs an IM application to open a window for conversation, and uses the window for a talk with the buddy. She may open several conversation windows to talk with some of her buddies at the same time. To realize this, each SEND message MUST have a Conversation-ID header field to identify the conversation it belongs. The Conversation-ID field MUST have a globally unique value like a Message-ID, which is also a globally unique identifier of the SEND message given by the client. The initial client to start the conversation thread with others MUST assign a value of Conversation-ID. It MAY reuse its Message-ID as the Conversation-ID. 3.5.3. Multiparty Conversation While PePP's basic IM mechanism is for one-to-one conversation, it can be extended to a simple multiparty IM conversation. If a participant of an already established IM conversation wants somebody to join, he send a SEND request message to the user with the current Conversation ID and the Reply-To header whose value is a list of recipients. Then the invited user joins the conversation by sending his message with the specified Conversation ID to all the recipients described in the Reply-To field. Obviously, this method of multiparty conversation has two problems. Sugano et al. [Page 19] INTERNET DRAFT PePP Specification April 2000 One is a scalability problem if the number of participants increases, and the other is it does not provide a means to delete the recipient when one participant quits the conversation. But, we think usual IM conversation is shared by very small number of users, and it will be closed in a short time. It is expected that it would not cause so much practical problems. 3.6. Character and Content Encoding For character encodings, PePP clients MUST accept the UTF-8 encoding of the ISO/IEC 10646 (UCS-4) character set, and MUST NOT cause errors by handling them. The user agent MUST display the content of presence information, instant messages, and other messages for at least US-ASCII part of UTF-8 encoding. Content or character encoding method is declared in 'charset' attribute in Content-Type header as in the example below. Content-Type: text/plain; charset=UTF-8 For the content type which has 'charset' as its attribute, specifying encoding method in 'charset' is STRONGLY RECOMMENDED. If the content type is text/xml, character encoding MAY be specified in the XML declaration as in the following example. In this case, the XML declaration is used. PePP servers and proxies MUST NOT cause an error for arbitrary content of presence information and instant messages in any content encodings. PePP servers and proxies MUST deliver the content of presence information and instant messages to the targets. 4. Considerations Regarding IMPP Requirements The IMPP Requirements document [Reqts] describes that an interoperable and widely-deployable standard protocol for IM/Presence must be scalable, secure, and appropriate for use with wireless devices. This section contains the considerations about PePP's strength and weakness for these criteria. Additionally, we give a note on the requirement for the separability of IM and Presence services. Sugano et al. [Page 20] INTERNET DRAFT PePP Specification April 2000 4.1. Scalability There are many aspects to scalability issues. We have considered the following features in the design of PePP; (1) the option to distribute server load over multiple servers, (2) the avoidance of processing bottlenecks where a delay in processing one message blocks other messages. (3) the avoidance of connection bottlenecks where a single huge message blocks many smaller messages. As a means to reduce the load of the servers, PePP allows any command to be redirected to an alternate server. This enables various strategies for dynamically allocating server resources and load balancing. To avoid the processing bottlenecks, PePP allows the responses to be received in the different order from that of requests by utilizing the Request ID in the messages so that the response can be matched with the corresponding request. There are two typical solutions to avoid the connection bottlenecks, data chunking/interleaving on a single connection, or the creation of multiple parallel connections. PePP has adopted the latter because it seems reasonable to open a new connection to send a huge data during an IM conversation. Another reason is that command-level chunking/interleaving is difficult in PePP as its command syntax is based on HTTP. 4.2. Security We have adopted the following security model for the IM/Presence services in PePP. 4.2.1. Trust model We assume the network is not trustworthy at all. Once authenticated each other, client-server and server-server relations are considered to be fully trustworthy. That is, the servers are trustworthy in the sense that; * the servers disclose presence information and/or IMs to authorized parties only. * the servers distribute presence information and/or IMs uncorrupted. * the IM servers relay IMs only from authorized senders. However, even though a user could trust the home server and servers Sugano et al. [Page 21] INTERNET DRAFT PePP Specification April 2000 are mutually trustworthy, other servers may be less trustworthy for the user. For instance, the other domain might not support any transport security for the Client connections. The current specification of PePP does not have a mechanism of knowing the security level of other domains. 4.2.2. Transport Security As we cannot assume the network is trustworthy, IM/Presence services require transport security to prevent tapping and tampering of messages. PePP adopts TLS for this purpose. The Server Connections are STRONGLY RECOMMENDED to be encrypted using TLS. 4.2.3. Confidentiality of Presence Information Presence information may be shared with an indefinitely large set of WATCHERS. Thus, end-to-end content encryption for each subscriber is too costly and impractical. If transport security is assumed, it is reasonable to provide no further content encryption. We believe access control preferences for presence information to provide an acceptable level of privacy control in PePP. 4.2.4. Integrity of Presence Information Under the trust model stated above, we trust all servers to not corrupt or alter presence information. Thus, PePP does not provide any additional mechanism to protect the integrity of presence information beyond the TLS transport security. Obviously, this is a weakness of PePP. We cannot say there is no more threat of the "Man-in-the-Middle" atack. To avoid this, we have to provide a means to put a digital signature on presence information. Because presence information in PePP is a set of individual sections, a digital signature is needed to each sections individually but this might be costly. So, it might be desirable to merge some sections together and sign on the merged sections. Even if digital signature is available, there is another threat of the replay attack. But, if a timestamp could be included at the time of digital signature, it would be helpful to avoid the apparent attacks while this is not a perfect solution. 4.2.5. Confidentiality of IM Sugano et al. [Page 22] INTERNET DRAFT PePP Specification April 2000 As PePP provides a basic functionality for transport security using TLS, IMs can be securely transported on the wire. However, only this does not provide the end-to-end security. For instance, a malicious server administrator can read the content of IM conversation. To provide the end-to-end security, PePP has an optional feature to establish a virtually direct connection between the clients which can be encrypted by TLS entirely. This assumes that the both clients have their digital certificates for their identities. Once such a direct connection is established, the clients can talk completely securely without so much overhead. We once considered the adoption of the message-level encryption standards such as S/MIME or OpenPGP. However, these standards impose the clients too much overhead, and seems to be impractical especially for the mobile devices. Moreover, if we assume transport security, this also implies the inefficiency of double-encryption. 4.2.6. Access Control PePP's section mechanism provides fine-grained access control over published presence information. A publisher can specify exactly which sections any particular party will see. For example, some WATCHERs can be shown IM presence but not shown cell phone presence. Moreover, by using the same section name for different sections, WATCHERs can be show different values for the same fields. We call this feature "personae", and think it is very useful for privacy- sensitive applications. 4.3. Wireless Wireless devices usually have limited computing and communication resources. As a result, more concise protocols are better and binary formats can be most efficient. However, PePP has adopted text-based formats for readability, extensibility, and ease of debugging. PePP's section-based presence format offers opportunities to reduce the size of tranferred content. For example, PePP allows selective subscription, which allows SUBSCRIBERs to receive only an interesting subset of all presence information sections. We think this selectivity is especially desirable for a wireless environment. 4.4. Separability of Services Sugano et al. [Page 23] INTERNET DRAFT PePP Specification April 2000 PePP is designed as an integrated protocol for both IM and Presence Services. However, the requirements document seems to require that the protocol MUST allow separation of these services; 2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available independent of whether an INSTANT MESSAGE SERVICE is available, and vice-versa. Although PePP is a single protocol for IM and Presence Services, we think it allows the two services to be provided separately. As PePP is originally designed for Presence Service, PePP is applicable as a protocol for the Presence Service without IM. A presence section is generic for various communication means other than IMs, and a section for IM contains a URI as an IM address. This feature allows IM Service to be a distinct one from the Presence Service. If we could disable the functions in PePP for Presence Service, it seems to be able to provide IM Service only. More concretely, functionality for establishing the PePP connections (LOGIN, STARTTLS, CALLBACK, CONNECT, and LOGOUT) and that for IM exchange (SEND and RECEIVE) seem to be sufficient to provide the IM Service in PePP. We assume that the IM addresses are available in an out-of-band manner. 5. PePP Messages 5.1. Message Overview The message format for the PePP protocol basically follows the formats for HTTP/1.1 [HTTP1.1]. Thus, a message consists of a start line, zero or more header fields, and possibly a message-body. A start line is either a request line or response line. A request line contains a PePP command, a PePP Resource as a target resource, a Request ID of the request itself, and a PePP Version identifier. PePP command details are described in Section 7. Headers are defined in Section 6. Headers defined here MAY appear at most once in a PePP message unless otherwise stated. Headers in PePP messages which are not defined in this specification MUST be ignored except for the case of SEND messages. A message-body conveys a content of presence information and instant messages. We use XML as a syntactic framework for the data format of presence information. MIME format is used when multiple presence sections are packed into a single message. MIME is also used for IMs. Sugano et al. [Page 24] INTERNET DRAFT PePP Specification April 2000 The PePP Version identifier used for PePP messages in this spec is "PePP/0.5" at present. 5.2. PePP Addresses A PePP Resource is represented as a form similar to the HTTP URL defined in HTTP/1.1 [HTTP1.1]. That URI is called the PePP Address of the resource. The same namespace is used for both Presence Service and IM Service in PePP. Because PePP is designed for PePP services, we use "pepp" for the protocol scheme name in the URL namespace. The syntax of PePP Addresses is defined as follows. PePP-Address = "pepp:" "//" host [":"port]] abs_path host = port = 1*DIGIT abs_path = In the PePP addresses, the local namespace can be extended utilizing paths like HTTP URL by the domain administrator or the owner of the resources for Presence Information or the INBOX address for IMs. PePP utilizes the PePP Address of the user's top resource as an identifier of the user, which is used in the From header of a PePP request. 5.3. Message Syntax The format of PePP messages is defined as follows, which is described in an augmented Backus-Naur Form (BNF) used in [HTTP1.1]. PePP-Message = PePP-Request | PePP-Response PePP-Request = PePP-Command SP Request-ID SP PePP-Version CRLF *(( PePP-Header ) CRLF) CRLF [message-body] PePP-Response = PePP-Status-Line *(( PePP-Header ) CRLF) CRLF [message-body] Sugano et al. [Page 25] INTERNET DRAFT PePP Specification April 2000 PePP-Status-Line = PePP-Version SP Request-ID SP Status-Code SP Reason-Phrase CRLF PePP-Version = "PePP" "/" 1*DIGIT "." 1*DIGIT Request-ID = token PePP-Command = LOGIN ; section 7.1 | LOGOUT ; section 7.2 | SUBSCRIBE ; section 7.3 | UNSUBSCRIBE ; section 7.4 | REQUESTNOTIFY ; section 7.5 | CHANGE ; section 7.6 | CANCEL ; section 7.7 | FETCH ; section 7.8 | NOTIFY ; section 7.9 | PULL ; section 7.10 | SEND ; section 7.11 | RECEIVE ; section 7.12 | CALLBACK ; section 7.13 | REDIRECT ; section 7.14 | SETACL ; section 7.15 | GETACL ; section 7.16 | CREATESECTION ; section 7.17 | DELETESECTION ; section 7.18 | PING ; section 7.19 | STARTTLS ; section 7.20 | CONNECT ; section 7.21 PePP-Header = From ; section 6.1 | Connection-Mode ; section 6.2 | Max-Content-Length ; section 6.3 | Subscription-Mode ; section 6.4 | Subscription-ID ; section 6.5 | Regarding ; section 6.6 | Change-Mode ; section 6.7 | Cancel-Type ; section 6.8 | Duration ; section 6.9 | Last-Modified ; section 6.10 | Section-ID ; section 6.11 | Section-Name ; section 6.12 | Location ; section 6.13 | Content-Type ; section 6.14 | Content-Length ; section 6.15 | Auth-State ; section 6.16 | SASL-Mechanism ; section 6.17 Sugano et al. [Page 26] INTERNET DRAFT PePP Specification April 2000 | Message-ID ; section 6.18 | Conversation-ID ; section 6.19 Status-Code and Reason-Phrase are described in Section 8. 6. PePP Headers 6.1. From The From header field contains the PePP address of the requesting entity. The From header MUST be included in all requests transported through the PePP server connections. If a server receives a request without the From header through one of a server connection, the server MUST return 400 Bad Request error. Requests only used in PePP client connections MAY not have this header. From = "From" ":" PePP-Address 6.2. Connection-Mode The Connection-Mode header field is included in LOGIN requests to indicate the mode of the connection. The value can take one of the two string tokens. Connection-Mode = "Connection-Mode" ":" ("server" | "client" | "direct") o server This value indicates the connection is requested in the "server" mode. o client This value indicates the connection is requested in the "client" mode. 6.3. Max-Content-Length The Max-Content-Length header field is included in LOGIN requests/responses and CALLBACK requests and indicates the size of an acceptable message body by the connection in decimal number of octets. The syntax is defined the same as in HTTP/1.1 [HTTP1.1]. Max-Content-Length = "Max-Content-Length" ":" 1*DIGIT Sugano et al. [Page 27] INTERNET DRAFT PePP Specification April 2000 6.4. Subscription-Mode The Subscription-Mode header field which appears in the SUBSCRIBE request specifies the mode of the requesting subscription. The value can take one of the three; notify, pull, renew. Subscription-Mode = "Subscription-Mode" ":" ("notify" | "pull" | "renew") o notify If the client requests to be notified when a change occurs in the target resource, this mode is specified. This is default. o pull The client tells the server that it would not like any changes to be notified. When the client wants to get the content of the resource in the Pull mode, it sends a PULL request to the server explicitly. o renew This mode is used in order to renew the subscription specified by the Subscription-ID. The response caused by the subscription request with this mode MUST NOT have a message body. 6.5. Subscription-ID The Subscription-ID header is used to specify the identifier of the subscription of concern in the request or the response. The server MUST specify this header field and value in the response to the SUBSCRIBE request. The client uses this value in the subsequent request to specify the subscription. Subscription-ID = "Subscription-ID" ":" token The value of Subscription-ID MUST be uniquely assigned at least modulo PePP resource. 6.6. Regarding The Regarding header is used in the SUBSCRIBE, FETCH or NOTIFY requests. The value can take one of two string tokens. Regarding = "Regarding" ":" ("value" | "control" ) If the Regarding header field appears in SUBSCRIBE or NOTIFY requests, it designates the kind of the subscription or notification. The "value" and "control" in this field specifies the subscription or Sugano et al. [Page 28] INTERNET DRAFT PePP Specification April 2000 notification is regarding the Presence Information and Subscribers Information respectively. If the Regarding header appears in a FETCH request, it means the kind of information the request tries to fetch. The meaning of the two values are same as in SUBSCRIBE and NOTIFY requests. The default value is "value". 6.7. Change-Mode The Change-Mode header is used in the CHANGE request to specify the behavior of the request. The value can take one of four string tokens. Change-Mode = "Change-Mode" ":" ("lease" | "permanent" | "renew" | "revert" ) o lease This mode is used to set or change the lease value of the presence section. It resets the lease timer of the section, and causes to send change notifications to the subscribers. o permenent This mode is used to set or change the permanent value of the presence section. If there is no lease value, it causes to send change notifications to the subscribers. o renew This mode is used to renew the lease value of the presence section. It resets the lease timer of the section, but does not cause any notifications. o revert This mode is used to remove the lease value of the presence section and revert to its permanent value. It causes to send change notifications to the subscribers. 6.8. Cancel-Type The Cancel-Type header is used in CANCEL requests and the NOTIFY requests caused by the CANCEL requests. Cancel-Type = "Cancel-Type" ":" ("cancel" | "retry") When a subscription is CANCELed, a NOTIFY request is issued to the WATCHERS in order to specify the expected action of the receiver client. If the server wants to direct the WATCHER client to retry subscription, the "retry" value MUST be set in the Cancel-Type header Sugano et al. [Page 29] INTERNET DRAFT PePP Specification April 2000 field. If the server wants to state the client not to retry to subscribe, the "cancel" value MUST be set in this field. The client SHOULD NOT subscribe to the same resource if the subscription was canceled with the value "cancel" in the Cancel-Type header. The Cancel-Type header is used in the CANCEL requests to specify the Cancel-Type header in the NOTIFY request caused by it. If this header is omitted in the CANCEL request, the value of "cancel" is used. 6.9. Duration The Duration header field specifies a lifetime of the lease value of the presence section in an integer second count if it is used in a CHANGE request or its response. The response for the CHANGE request with the Change-Mode 'lease' and 'renew' MUST contain the Duration header field. Such a CHANGE request MAY contain the Duration header as the client's request, but the server MAY ignore the value based on its policy. The client MUST use the specified value in the response as the duration for the presence section. The Duration header is also used in SUBSCRIBE request issued by the Home Server to specify a lifetime of the subscription. The response for the SUBSCRIBE request MUST contain the Duration header that specifies the duration of the subscription. The Home Server MUST use the specified duration value in the response even if it specified a different value in the SUBSCRIBE request. Duration = "Duration" ":" 1*DIGIT 6.10. Last-Modified The Last-Modified header field specifies the date/time of the latest change of the transported content. It is specified by the server. For Presence Information, each presence section has a last-modified value, and the value is changed in the following four cases; a) a CHANGE request changes the lease value, b) the lease value expires and the value changes to the permanent value, c) the permanent value is changed when the lease value is not set, d) the lease value is removed. The generated NOTIFY request message MUST have the Last- Modified header field containing this value. The response of a SUBSCRIBE or FETCH request MAY have MIME Multipart content with the multiple presence sections. In this case, the Sugano et al. [Page 30] INTERNET DRAFT PePP Specification April 2000 Last-Modified header MUST appear as one of the MIME-part-headers of each body part of the multipart entity. The date/time format is specified as follows. It is one of the format specified in ISO 8601 [ISO8601]. Last-Modified = "Last-Modified" ":" date "T" time "Z" date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; year-month-day time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; hour:minute:second (00:00:00 - 23:59:59) Example: 1999-12-08T18:05:23Z 6.11. Section-ID The Section-ID header field specifies the unique identifier of the presence section. When a presence section is to be created, the CREATESECTION request is issued by the client and the request MUST include this header. Its value is created by the client, and the uniqueness of the value is checked by the server. The CHANGE and DELETESECTION requests MUST contain this header as well. This header MAY also appear in the FETCH and CANCEL requests and responses to the FETCH requests. Section IDs are not to be shown to WATCHERS. Section-ID = "Section-ID" ":" token 6.12. Section-Name The Section-Name header field specifies the section name of the presence section. Section names are used by WATCHERS to specify the presence sections. When a presence section is to be created, the CREATESECTION request MUST include this header and the value. Section-Name = "Section-Name" ":" token 6.13. Location The Location header field specifies the PePP resource to be redirected. The REDIRECT request and the NOTIFY request caused by it MUST include the Location header. Location = "Location" ":" PePP-Address Sugano et al. [Page 31] INTERNET DRAFT PePP Specification April 2000 6.14. Content-Type The Content-Type header field indicates the media type of the message body sent to the recipient. The syntax of the media type is defined the same as in HTTP/1.1[HTTP1.1]. As stated in section 3.6., if the media type has 'charset' attribute, specifying encoding method in 'charset' attribute is STRONGLY RECOMMENDED. Content-Type = "Content-Type" ":" type "/" subtype *(";" parameter) 6.15. Content-Length The Content-Length header field indicates the size of the message body, in decimal number of octets. The syntax is defined the same as in HTTP/1.1 [HTTP1.1]. Content-Length = "Content-Length" ":" 1*DIGIT 6.16. Auth-State The Auth-State header specifies the status of authentication process in the LOGIN request. Auth-State = "Auth-State" ":" ("init" | "continue" | "abort") 6.17. SASL-Mechanism The SASL-Mechanism header specifies the SASL mechanism in the LOGIN request or the response to the LOGIN request. When used in the request, one SASL mechanism the client wants to use MUST be specified. When used in the response, one or more mechanisms which the server supports MAY be specified. SASL-Mechanism = "SASL-Mechanism" ":" mechanism *(LWS mechanism) 6.18. Message-ID The Message-ID header specifies the identifier of each IM, which distinguishes the message from others. The client MUST generate the Message ID unique to the PePP address for each IM. This header MUST appear in a SEND request. Sugano et al. [Page 32] INTERNET DRAFT PePP Specification April 2000 Message-ID = "Message-ID" ":" token 6.19. Conversation-ID The Conversation-ID header is used in the SEND request to identify the conversation channel shared by the participants of IM exchange. Here, a 'conversation channel' means a virtual channel which consists of a thread of the IM conversation. When a client replies to an IM in its same conversation channel, the SEND request for the reply MUST have the Conversation-ID header with the same value. Conversation-ID = "Conversation-ID" ":" token 7. PePP Methods This section describes the methods used in the PePP messages. We use the following notation to specify the allowable modes of connections and the directions of requests for each method. s->s : Server Connections. c->s : Client Connections, Client-to-Server direction. s->c : Client Connections, Server-to-Client direction. c->c : Direct Connections. 7.1. LOGIN 7.1.1. Command "LOGIN" 7.1.2. Direction s->s c->s c->c 7.1.3. Headers From Auth-State SASL-Mechanism Connection-Mode Max-Content-Length Sugano et al. [Page 33] INTERNET DRAFT PePP Specification April 2000 7.1.4. Description In order to establish the PePP connection, the initiator client or server MUST issue a LOGIN request to the other peer server to start authentication process. The Connection-Mode header indicates the mode of the required connection. When a client logins its Home Server, it MUST LOGIN the server in the "client" mode. When a server tries to open a connection with servers in the different domains, it MUST LOGIN the target server in the "server" mode. If the authentication process is successfully fulfilled, a PePP connection is established between the initiator and the target. Otherwise, the initiator MUST not send any commands. If it try to send other command in that case, the target server MUST return 401 Unauthorized error. The authentication process is not necessarily completed in a single request/response pair, but it can be fulfilled in a sequence of the request/response pairs. The Auth-State header MUST be used to indicate the state of the authentication process. The "init" Auth- State value indicates the initial request in the process, the "continue" value indicates it is subsequent requests. The SASL- Mechanism header is used to exchange the SASL mechanism supported by the initiator and the target server. Once a PePP connection is established, the initiator MUST NOT send another LOGIN request to the same connection. The initiator MUST NOT issue another LOGIN request with "init" Auth-State value in the midst of the authentication process. In either case, 406 Authentication Failed response is returned by the server. The LOGIN request MAY be preceded by the STARTTLS request when the implementations support TLS for a secure PePP connection. 7.2. LOGOUT 7.2.1. Command "LOGOUT" 7.2.2. Direction s->s c->s s->c c->c Sugano et al. [Page 34] INTERNET DRAFT PePP Specification April 2000 7.2.3. Headers 7.2.4. Description In order to terminate the currently established PePP connection, the either side of the connection SHOULD issue a LOGOUT request in a normal situation. The issuer of the LOGOUT request SHOULD wait its response to confirm the other peer is to send nothing. 7.3. SUBSCRIBE 7.3.1. Command "SUBSCRIBE" SP PePP-Address 7.3.2. Direction s->s c->s 7.3.3. Headers From [Subscription-Mode] [Subscription-ID] [Regarding] [Duration] 7.3.4. Discription The SUBSCRIBE method is used to declare a subscriber's interest at a PePP resource. The success of SUBSCRIBE request to a resource causes a change in the Subscribers Information at the resource. A SUBSCRIBE request MAY include 'Subscription-Mode' header, whose possible value is "notify", "pull", and "renew". If the "notify" value is specified, any changes in the subscribed sections will cause a notification message from the server. If the "pull" value is specified, the server MUST NOT send notification messages for this subscription unless the subsequent REQUESTNOTIFY message requests otherwise. The "renew" value is only specified by the Home Server of the subscribers in the case of renewing the subscription specified by the 'Subscription-ID' header field. There are two kinds of subscriptions regarding the information to be Sugano et al. [Page 35] INTERNET DRAFT PePP Specification April 2000 subscribed; value and control. A SUBSCRIBE request MAY have 'Regarding' header to designate the kind of subscription. Possible values for this header are 'value' and 'control' respectively. The default is 'value', which means a usual subscription to the presence information. If 'Regarding: control' is specified, the client subscribes to the Subscribers Information at the resource (see Section 11). For a SUBSCRIBE request with 'Regarding: value' header field, the target server determines the permitted presence sections to be shown based on the ACCESS RULES of the target resource. The response for the SUBSCRIBE request MUST contain the presence information of the allowed presence sections unless it is a "renew" request. Even if the ACCESS RULE changes after the subscription, the currently shown set of presence sections will not change until the client issues another SUBSCRIBE request. The response to a successful SUBSCRIBE request other than "renew" MUST contain 'Subscription-ID' header specifying the unique identifier of the subscription, and the 'Duration' header field specifying the amount of the duration time in seconds. The Home Server MUST maintain the subscription ID and the duration value in relation with the subscriber's connection ID, and MUST renew the subscription on behalf of the subscriber's client. The target server MUST NOT discard a subscription information before it expires in a normal situation. The Home Server MUST relay the response containing the subscription ID, but the client does not have to refer or specify any duration value. The maximum number of subscription at a particular resource can be set. In this case, if the server receives SUBSCRIBE requests exceeding the maximum, it MAY return a '505 Too Many Subscription' error. PePP does not offer any particular method to get the list of presence sections. So, one who wants a list of presence sections should issue a SUBSCRIBE request. While PePP does not offer any method to specify whether or not the pull mode subscription is allowed, an implementation MAY provide a method to disallow it in an out-of-band fashion. 7.4. UNSUBSCRIBE 7.4.1. Command "UNSUBSCRIBE" SP PePP-Address Sugano et al. [Page 36] INTERNET DRAFT PePP Specification April 2000 7.4.2. Direction s->s c->s 7.4.3. Headers From Subscription-ID 7.4.4. Description The UNSUBSCRIBE method is used to terminate a previously established subscription. It MUST include a 'Subscription-ID' identifying the subscription to be unsubscribed. The absence of this header causes an error response. This method can be used only by the relevant subscribers. 7.5. REQUESTNOTIFY 7.5.1. Command "REQUESTNOTIFY" SP PePP-Address 7.5.2. Direction s->s c->s 7.5.3. Headers From Subscription-ID *(Section-Name) 7.5.4. Description The REQUESTNOTIFY method is used to require change notifications on the presence sections specified by the Section-Name header fields through the already established subscription. The subscription is identified by the specified Subscription-ID, and, if the subscription does not exist, it will cause a '404 Subscription Not Found' error. More than one Section-Name header fields MAY be specified at once. The REQUESTNOTIFY request always overwrite the subscription mode of each presence section. I.e. the presence sections specified in the Sugano et al. [Page 37] INTERNET DRAFT PePP Specification April 2000 Section-Name headers change to the Notify mode and other sections change to the Pull mode. If no Section-Name header is specified, all sections become to be subscribed in the Pull mode. 7.6. CHANGE 7.6.1. Command "CHANGE" SP PePP-Address 7.6.2. Direction c->s 7.6.3. Headers From Section-ID Change-Mode Content-Length [Duration] [Content-Type] 7.6.4. Description The CHANGE method is used to alter the content stored at a given resource. A CHANGE request MUST be targeted to a single presence section by specifying the Section-ID header. Section-ID header is mandatory and its absence causes a '400 Bad Request' error. A successful CHANGE request may cause notifications to subscribers who subscribe to the relevant presence section. A CHANGE request MUST have a Change-Mode header field. The possible value is one of the four: "lease", "permanent", "renew", and "revert". A CHANGE request with the Change-Mode "lease" or "renew" MAY contain the Duration header field which specifies the client's request of the duration of the lease value. If "lease" is specified, the content of the message body is set as the lease value of the presence section. The duration MAY be specified by the Duration header, but the client MUST use the value specified by Duration header of the response even if it is different. The successful CHANGE request resets the lease timer of the section and causes notification messages to subscribers. If the lease value is not renewed within the amount of the specified duration value, it expires and the section reverts to its permanent value. Sugano et al. [Page 38] INTERNET DRAFT PePP Specification April 2000 If "permanent" is specified, the content of the message body is set as the permanent value of the presence section. If no lease value is set, it causes to send change notifications to the subscribers. If "renew" is specified, the lease value of the presence section is renewed. It resets the lease timer with the duration specified by the Duration header field in the response. It does not cause any notifications. If "revert" is specified, the lease value is removed and the value of the presence section reverts to its permanent value. It causes notification messages to subscribers. 7.7. CANCEL 7.7.1. Command "CANCEL" SP PePP-Address 7.7.2. Direction c->s 7.7.3. Headers From [Section-ID] [Subscription-ID] [Cancel-Type] 7.7.4. Description The CANCEL method is used to direct the target resource to discard the subscription specified in the Subscription-ID header. This is only issued by the client of the PRESENTITY. When a subscription is canceled by a successful CANCEL request, a NOTIFY request message reporting the cancellation is sent to the subscriber. If the CANCEL request contains the Cancel-Type header field (possible values are 'retry' and 'cancel'), the resulting NOTIFY request MUST contain the Cancel-Type header field with the same value. If the CANCEL request does not contain the Cancel-Type header, the resulting NOTIFY request MUST contain the Cancel-Type header with the value 'cancel'. Even if the subscription to be canceled is in the Pull mode, such a Sugano et al. [Page 39] INTERNET DRAFT PePP Specification April 2000 reporting NOTIFY message SHOULD be issued. However, in the case that the NOTIFY message is not delivered to the subscriber successfully, the subscriber may send a PULL request through the CANCELed subscription. In this case, the server MUST retrun the '404 Subscription Not Found' error. If the CANCEL request specifies neither Subscription-ID nor Section- ID headers, all the subscription SHOULD be canceled at the target PePP resource. If the CANCEL request has the Section-ID header and does not include the Subscription-ID header, all the subscriptions in relation to the specified section SHOULD be canceled. If there the subscription specified by the Subscription-ID header does not exist, it MUST cause 404 Subscription Not Found error. 7.8. FETCH 7.8.1. Command "FETCH" SP PePP-Address 7.8.2. Direction c->s 7.8.3. Headers From Regarding [Section-ID] 7.8.4. Description The FETCH method is used to get presence information and/or control information in the targeted resource. This method is mainly used for control use by the owner of the resource. FETCH requests can be targeted both to a resource and to a presence section contained in a resource. If the FETCH request contains the Section-ID header, the content of the specified presence section is returned. The response MUST also include the Section-ID header. When targeted to an entire resource, and if the resource contains multiple sections, the contents of multiple sections are returned in a single response formatted in MIME multipart. Each part MUST contain the Section-ID header whose value is the Section ID of the corresponding section. Sugano et al. [Page 40] INTERNET DRAFT PePP Specification April 2000 7.9. NOTIFY 7.9.1. Command "NOTIFY" SP PePP-Address 7.9.2. Direction s->s c->s 7.9.3. Headers From Subscription-ID Section-Name Content-Length Content-Type [Regarding] [Cancel-Type] 7.9.4. Description The NOTIFY method is used (1) to report CHANGEs inside a subscription; and (2) to report CANCELs of subscriptions to the subscribers. The NOTIFY request MUST include the Subscription-ID header to specify the subscription by which the notification is required. This specification does not specify the behavior of the receiver in the case the Subscription-ID is missing. The target address of the NOTIFY request MUST be the address in the From header of the corresponding SUBSCRIBE request. The Regarding header has the same value as specified in the corresponding SUBSCRIBE request. The default value is 'value'. If a subscription at a resource is canceled by a successful CANCEL request, it causes the NOTIFY request to the subscriber. Such a NOTIFY MUST contain the Cancel-Type header field. If the corresponding CANCEL request contains the Cancel-Type header field with the value 'retry', the resulting NOTIFY request MUST contain the Cancel-Type header field with the same value. Otherwise, the NOTIFY request MUST contain the Cancel-Type header field with the value 'cancel'. Sugano et al. [Page 41] INTERNET DRAFT PePP Specification April 2000 7.10. PULL 7.10.1. Command "PULL" SP PePP-Address 7.10.2. Direction s->s c->s 7.10.3. Headers From Subscription-ID [Section-Name] 7.10.4. Description The PULL method is used to get the content of the resource which is currently subscribed by the same issuer of this message. The PULL request MUST contain 'Subscription-ID' header, and the value of this header MUST contain a valid subscription ID. If the PULL request does not have a Section-Name header, the response contains all the disclosed sections encoded in MIME Multipart. 7.11. SEND 7.11.1. Command "SEND" SP PePP-Address 7.11.2. Direction s->s c->s s->c c->c 7.11.3. Headers From Message-ID Content-Length Content-Type [Conversation-ID] Sugano et al. [Page 42] INTERNET DRAFT PePP Specification April 2000 [Reply-To] 7.11.4. Description The SEND method is used to send arbitrary content to a targeted PePP address. This is usually used for IMs. The SEND request MUST contain the Message-ID header whose value is the globally unique identifier of the message. The client MUST have responsibility for the uniqueness. If the receivers are set by the RECEIVE requests at the target resource of the SEND request, the server MUST issue another SEND request with the same PePP Resource and header fields to the receiver connections. If the target resource has no receivers, the '502 Service Unavailable' error is returned. When the client wishes to start a conversational IM exchange, the SEND request MUST contain the Conversation-ID header field whose value is a globally unique identifier to be shared by the participants of the conversation. Assume that a client has reveived an IM with the Conversation-ID header. If the client wishes to reply to it in the same conversation channel, it MUST specify the same Conversation-ID field in the reply SEND message. The SEND request is REQUIRED to tranport any MIME entity. Thus, it MAY contain any legal MIME header which may not be defined here. The servers MUST forward the SEND message as is when the message is relayed to the clients or other servers. That is, the servers MUST NOT delete or modify any header which appears in the SEND message. 7.12. RECEIVE 7.12.1. Command "RECEIVE" SP PePP-Address 7.12.2. Direction c->s 7.12.3. Headers 7.12.4. Description The RECEIVE method is used to specify the connection to forward the Sugano et al. [Page 43] INTERNET DRAFT PePP Specification April 2000 delivered SEND message at the target resource. When the server receives the RECEIVE request, the Client connection of the issuer client is set as a 'Receiver' connection at the target resource. More than one 'Receiver' connections MAY be set if other clients issue the RECEIVE request at the same resource. The server MUST manage the 'Receiver' connections of every resources in it, and, when it receives a SEND message targeted at the resource, it MUST issue the new SEND requests with the same PePP-Address and headers to its 'Receiver' connections. 7.13. CALLBACK 7.13.1. Command "CALLBACK" 7.13.2. Direction s->c 7.13.3. Headers Max-Content-Length [Location] [Connection-Mode] 7.13.4. Description The CALLBACK method is used by the server to ask the client to create a new "backup" Client Connection. The server will use the newly established connection to send the message whose body size exceeds the Max-Content-Length values of the existing Client Connections. The CALLBACK request MUST contain the Max-Content-Length header field to tell the required value for new connection. The server MAY specify the Location header field to specify a different server location and/or port number to be called back from the client. If Location header value contains other than server and port number, rest part of PePP-Address will be ignored. If the client accepts the request, it returns '200 OK' as the response and it MUST issue a LOGIN request to a newly opened TCP Sugano et al. [Page 44] INTERNET DRAFT PePP Specification April 2000 connection to establish a "backup" Client Connection. If the client rejects the request, the client returns '402 Permission Denied' response. The Target Server will use this request to ask the Target Client for creating "raw TCP connection", which provides the Direct Connection. In this case, the CALLBACK command MUST contain the Connection-Mode header field with the value "direct". 7.14. REDIRECT 7.14.1. Command "REDIRECT" SP PePP-Address 7.14.2. Direction c->s 7.14.3. Headers Location 7.14.4. Description The REDIRECT method is used to specify the address for redirection of the SUBSCRIBE or SEND request to the PePP resource. A successful REDIRECT request results in returning the 300 Moved Temporary response to the subsequent SUBSCRIBE or SEND requests. Established subscriptions at the time of the REDIRECT request are still alive as they were. PULL requests through the subscriptions MAY still be accepted. As the subscribers cannot know the target resource was REDIRECTed, the client MUST issue CANCEL request in order to tell the subscribers that the resource was REDIRECTed. The destination resource of the redirection is specified in the Location header. The REDIRECT request without a Location header cancels the redirection settled before. Even if no redirection was settled, cancellation request is returned with 200 OK. 7.15. SETACL 7.15.1. Command Sugano et al. [Page 45] INTERNET DRAFT PePP Specification April 2000 "SETACL" SP PePP-Address 7.15.2. Direction c->s 7.15.3. Headers Content-Type Content-Length 7.15.4. Description The SETACL method is used to specify the ACL at the targeted resource. The message body of the SETACL request is used as a new ACL. The format of the ACL is described in Section 12. The owner of the resource, or a user specially authorized by the system administrator, can issue the SETACL requests. 7.16. GETACL 7.16.1. Command "GETACL" SP PePP-Address 7.16.2. Direction c->s 7.16.3. Headers 7.16.4. Description The GETACL method is used to acquire the ACL at the targeted resource. The successful response contains the currently set ACL at the resource in its body part. The format of the ACL is described in Section 12. The owner of the resource, or a user specially authorized by the system administrator, can issue the GETACL requests. 7.17. CREATESECTION 7.17.1. Command Sugano et al. [Page 46] INTERNET DRAFT PePP Specification April 2000 "CREATESECTION" SP PePP-Address 7.17.2. Direction c->s 7.17.3. Headers Section-ID Section-Name Content-Type Content-Length 7.17.4. Description The CREATESECTION request is used to create a new presence section. Section-ID and Section-Name are mandatory headers and, if either of those is omitted, it causes 400 Bad Request error. The message body is set as a permanent value of this section. The server checks the uniqueness of the Section-ID at the resource, and return 405 Section Already Exists if there already exists. This request does not contain any content of the presence section. 7.18. DELETESECTION 7.18.1. Command "DELETESECTION" SP PePP-Address 7.18.2. Direction c->s 7.18.3. Headers Section-ID 7.18.4. Description The DELETESECTION request is used to delete the specified presence section. The Section-ID header is mandatory. If absence, 400 Bad Request error is returned. If the section is still subscribed, a '407 Subscription Still Exists' error is returned. 7.19. PING Sugano et al. [Page 47] INTERNET DRAFT PePP Specification April 2000 7.19.1. Command "PING" 7.19.2. Direction s->s c->s s->c c->c 7.19.3. Headers 7.19.4. Description The PING request is used by the server or the client to confirm that the PePP connection is alive. When this request is received, the receiver MUST return '200 OK' response. 7.20. STARTTLS 7.20.1. Command "STARTTLS" 7.20.2. Direction s->s c->s 7.20.3. Headers 7.20.4. Description A client or server MAY issue STARTTLS request to upgrade the existing TCP connection to the TLS [TLS] (formerly known as SSL) enabled one instead of using separate port for "secure" PePP connection. Implementations that support TLS SHOULD issue a STARTTLS request prior to issuing any other requests. A TLS negotiation begins immediately after the "200 OK" response from the another peer. Once a STARTTLS command issued, the initiator MUST NOT issue further requests until a server response is received and the TLS negotiation is completed. Sugano et al. [Page 48] INTERNET DRAFT PePP Specification April 2000 Once the client credentials are successfully exchanged using TLS negotiation, the "EXTERNAL" SASL mechanism MAY be used in the subsequent LOGIN process. The "PLAIN" SASL mechanism MUST NOT be used if the STARTTLS upgrading process fails to establish a fully strong encryption layer. The implementation which does not support TLS SHOULD return the "501 Not Implemented" response. In this case, the client MUST authenticate itself in the following LOGIN process. 7.21. CONNECT 7.21.1. Command "CONNECT" SP PePP-Address 7.21.2. Direction s->s c->s 7.21.3. Headers From 7.21.4. Description The CONNECT method is used to establish the Direct Connection between clients. The established connection will provide a private conversation channel for IMs. The CONNECT request issued by a client intended to the other client is sent to the Home Server, and is forwarded to the Target Server by opening a new connection. Then, the Target Server issues a CALLBACK request to the destination client to tell the request from the initiator client (see Section 3.3.3 for details). 8. Status Codes The policy for assigning PePP status codes basically follows the convention used in HTTP/1.1 [HTTP1.1]. - 1xx: Informational - Request received, continuing process - 2xx: Success - The action was successfully received, understood, and accepted Sugano et al. [Page 49] INTERNET DRAFT PePP Specification April 2000 - 3xx: Redirection - Further action must be taken in order to complete the request - 4xx: Client Error - The request contains bad syntax or cannot be fulfilled - 5xx: Server Error - The server failed to fulfill an apparently valid request 8.1. 1xx 8.1.1. 100 Authentication Continued The request for authentication has been accepted and the authentication process is continued. 8.2. 2xx 8.2.1. 200 OK 8.2.2. 201 Subscription Created It appears in the response to a SUBSCRIBE request, reporting the successful result. In the subscription for 'Regarding: value' and 'control', the relevant content MUST be contained in the response. 8.2.3. 202 Section Created It appears in the response to a CREATESECTION request, reporting the successful result. 8.3. 3xx 8.3.1. 300 Moved Temporary The requested resource has been assigned a new URI temporarily and the requester SHOULD resend the request to the specified resource. The new URI MUST be given by the Location header field in the response. It depends on the server's policy to select the 300 or 301 response. 8.3.2. 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use the returned URI. The new permanent URI MUST be given by the Location header field in the Sugano et al. [Page 50] INTERNET DRAFT PePP Specification April 2000 response. It depends on the server's policy to select the 300 or 301 response. 8.4. 4xx 8.4.1. 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. 8.4.2. 401 Unauthorized The request requires user authentication. The client MUST authenticate itself by the LOGIN request. 8.4.3. 402 Forbidden The server understood the request, but it has not been authorized. 8.4.4. 403 Resource Not Found The specified resource was not found at the server. 8.4.5. 404 Subscription Not Found The Subscription specified in the Subscription-ID header was not found at the resource. This status code MAY appear in the response to the UNSUBSCRIBE, CANCEL, PULL requests and the SUBSCRIBE request in "renew" mode. 8.4.6. 405 Section Already Exists The section specified in the Section-ID header of the CREATESECTION request already exists. 8.4.7. 406 Authentication Failed The authentication process has been failed. The reason for it is one of the followings. o The authentication process using the specified SASL-Mechanism was failed. o The LOGIN request does not specify any SASL-Mechanism. o The LOGIN request specifies inappropriate SASL-Mechanism. o In the midst of the authentication process, the client tries to start another authentication process by specifying Sugano et al. [Page 51] INTERNET DRAFT PePP Specification April 2000 'Auth-State: init'. This response MAY contain a SASL-Mechanism header specifying the applicable SASL-Mechanism. 8.4.8. 407 Subscription Still Exists The request has not been fulfilled because the subscription to the specified section still exists. This status code appears in the response to the DELETESECTION request. The client which has received this response MUST send a CANCEL request before requesting the DELETESECTION. 8.5. 5xx 8.5.1. 500 Internal Server Error The request has not been fulfilled because of the error internal to the server. 8.5.2. 501 Not Implemented The server does not support the functionality required to fulfill the request. 8.5.3. 502 Service Unavailable This status code is returned when the client issues the SEND request to the resource which any 'receiver' connection is not set. 8.5.4. 503 PePP Version Not Supported The server or the client does not support the specified version of PePP used for the request. 8.5.5. 504 Gateway Timeout The server forwarded the request to the specified server, but has not been received within the time that it was prepared to wait. the forwarded request has been timeout. 8.5.6. 505 Too Many Subscription The SUBSCRIBE request has not been fulfilled because the request exceeds the specified maximum number of subscription at the resource. When received this status code, the client SHOULD NOT retry subscription immediately. Sugano et al. [Page 52] INTERNET DRAFT PePP Specification April 2000 9. Presence Information Data Format 9.1. Overview In PePP, Presence Information is encoded in Well-Formed XML without a DTD. Although any XML components MAY appear as a presence data, only the elements defined in this documents have a meaning. Presence Information at a PePP resource is composed of a set of presence sections, each of which is contained in the
element. Each presence section has a unique identifier called Section ID, which is not to be shown to subscribers, and a section name which is sent to subscribers for the sake of selective subscription. However, both of section IDs and names are not included in the content of Presence Information. Instead, for each presence section, a display-name is contained in the content of PI to be displayed to subscribers. Display names are contained in the content of element. A typical example of Presence Information is availability of communication means, such as IM and telephone. Such information is contained in a sub-element. The element contains
, and and sub- elements. For IM, the
element contains the PePP address of the recipient. For the communication means where the target address can be expressed by a URL, the
element contains the URL (ex.
tel:+81-123-456-7890
). For other communication means, the element contains supplementary information for the communication means. Example:
pepp://pepp.org/Alice/iibox
 Out to Lunch. IM
Example:
tel:+81-123-456-7890
Sugano et al. [Page 53] INTERNET DRAFT PePP Specification April 2000 Telephone at Home
The element MAY have a sub-element, which specifies the device capability of the communication means or the user's preference. Although this document does not specifies the concrete format of capability, we will allow to contain a URL where a capability for the device is stored in other future standard format as CONNEG or CC/PP [CC/PP]. 9.2. Tag Descriptions 9.2.1. section Tag: section Context: top level Appearance: mandatory Sub-elements: display-name note ( communication | principal ) Description: The section tag is top-level tag for presence sections. 9.2.2. display-name Tag: display-name Appearance: mandatory Context: section Sub-elements: none Description: Text to be displayed by the client UI. 9.2.3. note Tag: note Appearance: optional Context: section Sub-elements: none Description: Text to be handled as a short note in relation to the presence information. 9.2.4. communication Tag: communication Appearance: mandatory Context: section Sugano et al. [Page 54] INTERNET DRAFT PePP Specification April 2000 Sub-elements: address communication-status capability Description: Information about communication means is contained. This element appears in a section element if the section is used to express status of a communication means. This element can have additional sub-elements. 9.2.5. communication-status Tag: status Appearance: mandatory Context: section Sub-elements: ( open | closed ) Description: Availability of the communication means. 9.2.6. open Tag: open Appearance: mandatory Context: status Sub-elements: ( busy | away ) Description: The open tag means that the communication device is available. It MAY contain other elements not defined here. 9.2.7. closed Tag: closed Appearance: mandatory Context: status Sub-elements: none Description: The closed tag means that the communication device is not available. 9.2.8. busy Tag: busy Appearance: optional Context: open Sub-elements: none Description: The communication device is available, but a communication request may not be noticed because the user is busy. 9.2.9. away Sugano et al. [Page 55] INTERNET DRAFT PePP Specification April 2000 Tag: away Appearance: optional Context: open Sub-elements: none Description: The communication device is available, but a communication request may not be noticed because the user is away from the device. 9.2.10. capability Tag: capability Appearance: optional Context: section Sub-elements: none Description: If this element appears, the capability information of the corresponding communication device can be retrieved. 9.2.11. address Tag: address Appearance: mandatory Context: communication Sub-elements: none Description: The address of the communication device in the form of URI. 9.2.12. principal Tag: principal Appearance: mandatory Context: section Sub-elements: principal-status Description: Information in relation to the relevant principal is contained. The principal usually has various status information other than any communication means. This tag is for such information. 9.2.13. principal-status Tag: status Appearance: mandatory Context: principal Sub-elements: none Description: Status information for the principal which may be used by the applications. Sugano et al. [Page 56] INTERNET DRAFT PePP Specification April 2000 10. Subscribers Information The owner or specially authorized user can get the information of the current subscribers at the resource. This is called Subscribers Information. The Subscribers Information is a list of subscription information at the resource, each of which contains the subscription ID, the subscriber's PePP address, the date of the subscription, and so on. The Subscribers Information can be acquired by a SUBSCRIBE or FETCH request in 'Regarding: control'. Even if the Section-Name header appears in this request, it MUST be ignored. If the 'Subscription- Type: Notify' is specified, any change at the Subscribers Information will be notified. The syntax of Subscribers Information is based on XML, and is defined by the following ABNF. information = "" 1*subscription "" subscription = "" subscription-ID subscriber created mode regarding "" subscription-ID = "" token "" subscriber = "" PePP-Address "" created = "" date "T" time "Z" "" mode = "" ("notify" / "pull") "" regarding = "" ("value" / "control") "" Here, the "created" element represents the date that the subscription was created. The format of the value is same as the Last-Modified header field specified in section 6.10. The "mode" element represents the Subscription-Mode of the subscription which is defined in section 6.4 and 7.3. The "regarding" element represents what property of the resource is subscribed. The value and its semantics is same as the Regarding header field in corresponding SUBSCRIBE request. Example: a1b2c3d4e5f6 pepp://pepp.org/bob 2000-06-10T09:10:43Z notify value Sugano et al. [Page 57] INTERNET DRAFT PePP Specification April 2000 .... 11. Access Control List 11.1. Overview Access Control in PePP has two aspects; one is to decide allowing or rejecting the access request from the requesters, and the other is to select which presence sections should be disclosed to the SUBSCRIBERS. The user controlling a PePP resource can indicate how to handle the requests to it specifying Access Control List (ACL). The PePP ACL specifies the action of the server at the time of receiving the following requests; SUBSCRIBE, SEND, FETCH, CHANGE, CANCEL, REDIRECT. For all of those requests but SUBSCRIBE, an allow-list and deny-list can be specified in the ACL. For SUBSCRIBE requests, a disclose-list can be specified for each section instead of an allow-list. This is a design decision based on our experience through the practice of presence services in our company. By default, all requests are handled as they are denied, or nothing is disclosed, unless the system configuration allows. Because presence and instant messaging services are pretty sensitive to privacy issues, we took a safer side. 11.2. ACL Functions 11.2.1. SUBSCRIBE For the SUBSCRIBE request, a basic action is 'deny' and 'disclose'. The ACL has a deny list and a disclose list for SUBSCRIBE. o Deny-list is a list of principals whose requests are denied. o Disclose-list is a set of lists, each of which is a list of principals allowed for each section. A deny-list and a disclose-list appears once in the ACL, and the deny-list has a priority over the disclose list. In other words, a request from a principal matching the deny-list is rejected regardless of the disclose-list. The default action is also 'deny'. Each section is specified by the Section ID and Section names does not appear in the ACL. This implies that it is possible to show more than one sections with the same name. The current specification does Sugano et al. [Page 58] INTERNET DRAFT PePP Specification April 2000 not forbid this situation. A 'default' tag MAY be assigned to one or more sections. The assigned section becomes a default section, which is shown when no section to be shown was specified explicitly. 11.2.2. SEND, FETCH, CHANGE, CANCEL, REDIRECT For the SEND, FETCH, CHANGE, CANCEL, and REDIRECT requests, a basic action is 'deny' and 'allow', same as the conventional ACLs. The ACL has a deny list and an allow list for them. o Deny-list is a list of principals whose requests are denied. o Allow-list is a list of principals whose requests are allowed. A deny-list and an allow-list appears once in the ACL, and the deny- list has a priority over the allow-list unless otherwise stated. In other words, a request from a principal matching the deny-list is rejected regardless of the allow-list. The default action is also 'deny'. The priority can be reversed by specifying the 'priority-allow' tag. In this case, the allow-list has a priority over the deny-list and the default action becomes 'allow'. 11.3. Syntax of ACL The syntax of ACL in PePP is based on XML as defined in this section. Command Names and Section IDs are case-sensitive. The syntax is defined by the following ABNF. acl = "" subscribe *other-command "" subscribe = "" [deny-list] disclose-list "" disclose-list = "" 1*section "" section = "
" section-body "
" section-body = section-id (default / all / user-group-list) user-group-list = *(user / group) default = "" other-command = "" command-body "" command-body = command-name [reverse-priority] [allow-list] [deny- list] command-name = "" command-token "" command-token = "SEND" / "FETCH" / "CHANGE" / "CANCEL" / "REDIRECT" reverse-priority = "" allow-list = "" (all / user-group-list) "" Sugano et al. [Page 59] INTERNET DRAFT PePP Specification April 2000 deny-list = "" user-group-list "" user = "" user-id "" group = "" group-name "" all = "" Here, tag is prepared for the future extension where a group of users can be specified as a principal. Example: pepp://pepp.fujitsu.com/suga
for-office1 pepp://pepp.fujitsu.com/sho group2
for-office2 group1 group2
private pepp://pepp.fujitsu.com/iwakawa pepp://pepp.fujitsu.com/sho
default
FETCH group1 group2 SEND Sugano et al. [Page 60] INTERNET DRAFT PePP Specification April 2000 pepp://foo.net/unknown 12. Sample Transcripts Consider Alice starts to connect to her home server and her PePP address is "pepp://pepp.fujitsu.com/alice". 12.1. LOGIN // In order to login the PePP service, the client initiate the LOGIN // request to establish a PePP connection. // Alice connects PePP service, // opening the PePP connection from her client to port ??? of // pepp.fujitsu.com LOGIN 00153678 PePP/0.5 From: pepp://pepp.fujitsu.com/alice SASL-mechanism: CRAM-MD5 Auth-State: init // Response from server. // A challenge is given as the content PePP/0.5 00153678 100 Authentication Continued Content-Type: text/plain Content-Length: xxx 1234.14782225@pepp.org // The client returns a response in the succeeding LOGIN request LOGIN 00153679 PePP/0.5 From: pepp://pepp.fujitsu.com/alice Auth-State: continue Content-Type: text/plain Content-Length: xxx Sugano et al. [Page 61] INTERNET DRAFT PePP Specification April 2000 alice b913a602c7eda7a495b4e6e7334d3890 // Authentication succeeded PePP/0.5 00153679 200 OK 12.2. CREATESECTION // Alice creates a new section containing an IM presence. // This content is set as a permanent value of this section. CREATESECTION pepp://pepp.fujitsu.com/alice 00153783 PePP/0.5 From: pepp://pepp.fujitsu.com/alice Section-ID: PublicIM Section-Name: IM Content-Type: text/xml Content-Length: yyy
Instant Message
pepp://pepp.fujitsu.com/alice/iibox
// The new section was successfully created. PePP/0.5 00153783 202 Section Created 12.3. CHANGE // Alice changes her presence information CHANGE pepp://pepp.fujitsu.com/alice 00153793 PePP/0.5 From: pepp://pepp.fujitsu.com/alice Section-ID: PublicIM Duration: 180 Content-Type: text/xml Content-Length: xxx
Instant Message Meeting, Room 5B Sugano et al. [Page 62] INTERNET DRAFT PePP Specification April 2000
pepp://pepp.org/alice/iibox
// Presence information was successfully changed PePP/0.5 00153793 200 OK Duration: 180 12.4. SUBSCRIBE // Bob subscribes to Alice's presence information. // Assumes that ACL specifies to show "PublicIM" (Section-ID) for // the subscription from Bob. The section has a Section-Name "IM". // The disclosed content of the presence information is returned // as an initial value. SUBSCRIBE pepp://pepp.fujitsu.com/alice 02658472 PePP/0.5 From: pepp://pepp.org/bob Subscription-Mode: Notify Regarding: value // Subscription has succeeded, and Bob's client receives the // response with Alice's PI at the moment. PePP/0.5 02658472 201 Subscription Created Subscription-ID: a1b2c3d4e5f6 Content-Type: multipart/mixed; boundary="Multipart0123456789" Content-Length: xxx --Multipart0123456789 Content-Type: text/xml Content-Length: zzz Last-Modified: 2000-06-10T09:10:43Z
Instant Message Meeting, Room 5B s
pepp://pepp.org/alice/iibox
--Multipart0123456789 ( if other section is allowed for Bob to subscribe, they will appear here.) --Multipart0123456789 Sugano et al. [Page 63] INTERNET DRAFT PePP Specification April 2000 12.5. NOTIFY // When Alice changes her presence, it is notified to the subscriber. NOTIFY pepp://pepp.org/bob 31975431 PePP/0.5 From: pepp://pepp.fujitsu.com/alice Section-Name: IM Subscription-ID: a1b2c3d4e5f6 Last-Modified: 2000-06-10T12:03:22Z Content-Type: text/xml Content-Length: xxx
Instant Message I'm back!
pepp://pepp.org/alice/iibox
// The client returns a successful response. PePP/0.5 31975431 200 OK 12.6. SEND // Bob sends IM to Alice. SEND pepp://pepp.fujitsu.com/alice/iibox 01348590 PePP/0.5 From: pepp://pepp.org/bob Message-ID: 200006101523.ZDFN0478//pepp.org/bob Conversation-ID: 200006101523.ZDFN0478//pepp.org/bob Content-Type:text/plain Context-Length: xxx Hello! // The server returns a successful response if the message is // deliverable. PePP/0.5 01348590 200 OK // Then the server fowards the message to the client connection. SEND pepp://pepp.fujitsu.com/alice/iibox 31978216 PePP/0.5 Sugano et al. [Page 64] INTERNET DRAFT PePP Specification April 2000 From: pepp://pepp.org/bob Message-ID: 200006101523.ZDFN0478//pepp.org/bob Conversation-ID: 200006101523.ZDFN0478//pepp.org/bob Content-Type:text/plain Context-Length: xxx Hello! // The Alice's client returns a successful response. PePP/0.5 31978216 200 OK 12.7. LOGOUT // Alice closes the PePP connection. LOGOUT 00258674 PePP/0.5 From: pepp://pepp.fujitsu.com/alice // The server returns a successful response. PePP/0.5 00258674 200 OK // Alice's client closes the TCP connection. 13. Security Considerations Security considerations are described in Section 4.2. 14. Acknowledgments Some of the ideas in this document are inspired by private correspondence with John Stracke, eCal Corp., especially for IM transfer and IM conversation. The authors gratefully acknowledge his contributions. 15. References [Model] M.Day, J.Rosenberg, H.Sugano, "A Model for Presence and Instant Sugano et al. [Page 65] INTERNET DRAFT PePP Specification April 2000 Messaging", RFC 2778, February 2000. [Reqts] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [RelURL] R.Fielding, "Relative Uniform Resource Locators", RFC1808 [HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", RFC2222, October 1997. [SASL-PLAIN] C. Newman, "Using TLS with IMAP, POP3 and ACAP", RFC2595, June 1999. [CRAM-MD5] J.Klensin, R.Catoe and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [TLS] T.Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC2246, January 1999. [MIME] N. Freed et al., "Multipurpose Internet Mail Extensions (MIME) Part One" to "Five", RFC 2045-2049, November 1996. [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC2396, August 1998. [ISO8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", 1988. [CC/PP] M.Nilsson, J.Hjelm, H.Ohto, "Composit Capabilities/Preference Profiles: Requirements and Architecture", W3C CC/PP Working Group, http://www.w3.org/TR/CCPP-ra/, February, 2000. 16. Authors' Addresses Hiroyasu Sugano Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan email: suga@flab.fujitsu.co.jp Akinori Iwakawa Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan email: iwakawa@flab.fujitsu.co.jp Koji Otani Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan email: sho@flab.fujitsu.co.jp Sugano et al. [Page 66] INTERNET DRAFT PePP Specification April 2000 Takashi Ohno Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan email: ohno@flab.fujitsu.co.jp Shingo Fujimoto Fujitsu Laboratories of America, Inc. 595 Lawrence Expressway Sunnyvale, CA 94086 USA email: shingo@fla.fujitsu.com Sugano et al. [Page 67]