idnits 2.17.1 draft-sugano-impp-proposal-pepp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2000) is 8708 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 233, but not defined == Missing Reference: 'Subscription-Mode' is mentioned on line 1578, but not defined == Missing Reference: 'Subscription-ID' is mentioned on line 1768, but not defined == Missing Reference: 'Regarding' is mentioned on line 1852, but not defined == Missing Reference: 'Duration' is mentioned on line 1714, but not defined == Missing Reference: 'Content-Type' is mentioned on line 1715, but not defined == Missing Reference: 'Section-ID' is mentioned on line 1815, but not defined == Missing Reference: 'Cancel-Type' is mentioned on line 1853, but not defined == Missing Reference: 'Section-Name' is mentioned on line 1896, but not defined == Missing Reference: 'Conversation-ID' is mentioned on line 1927, but not defined == Missing Reference: 'Reply-To' is mentioned on line 1929, but not defined == Missing Reference: 'Location' is mentioned on line 1999, but not defined == Missing Reference: 'Connection-Mode' is mentioned on line 2000, but not defined == Unused Reference: 'RelURL' is defined on line 2989, but no explicit reference was found in the text == Unused Reference: 'MIME' is defined on line 3001, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 3003, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. 'Model') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. 'Reqts') ** Obsolete normative reference: RFC 2616 (ref. 'RelURL') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' Summary: 10 errors (**), 0 flaws (~~), 20 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Sugano 3 Expires: December, 2000 A. Iwakawa 4 K. Otani 5 T. Ohno 6 S. Fujimoto 7 Fujitsu 8 June 2000 10 Privacy-enhanced Presence Protocol (PePP) 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This document describes a protocol designed for scalable and secure 39 Instant Messaging and Presence Services. The protocol, Privacy 40 enhanced Presence Protocol (PePP), has been developed for an 41 experimental Presence Service and recently extended to satisfy a 42 variety of requirements for the Internet-wide, interoperable 43 standards. This is a protocol proposal for the IMPP Working Group. 45 Table of Contents 47 1. Introduction ......................................... 4 48 2. Terminology .......................................... 4 49 3. Protocol Overview .................................... 6 50 3.1. Architecture ......................................... 6 51 3.2. Model for Presence Service ........................... 7 52 3.2.1. Privacy Requirements ................................. 7 53 3.2.2. Presence Sections .................................... 7 54 3.2.3. Section based Access Control ......................... 8 55 3.2.4. Lease Model of Presence Information .................. 9 56 3.2.5. Two Modes of Subscription ............................ 10 57 3.3. PePP Connections ..................................... 10 58 3.3.1. Client Connections ................................... 11 59 3.3.2. Server Connections ................................... 13 60 3.3.3. Direct Connections ................................... 15 61 3.4. Subscription Model ................................... 16 62 3.4.1. Behavior of Clients .................................. 17 63 3.4.2. Behavior of Home Servers ............................. 17 64 3.4.3. Behavior of Target Servers ........................... 18 65 3.5. Instant Messaging Service ............................ 18 66 3.5.1. Basic Architecture ................................... 18 67 3.5.2. IM Conversation ...................................... 19 68 3.5.3. Multiparty Conversation .............................. 19 69 3.6. Character and Content Encoding ....................... 20 70 4. Considerations Regarding IMPP Requirements ........... 20 71 4.1. Scalability .......................................... 21 72 4.2. Security ............................................. 21 73 4.3. Wireless ............................................. 23 74 4.4. Separability of Services ............................. 23 75 5. PePP Messages ........................................ 24 76 5.1. Message Overview ..................................... 24 77 5.2. PePP Addresses ....................................... 25 78 5.3. Message Syntax ....................................... 25 79 6. PePP Headers ......................................... 27 80 6.1. From ................................................. 27 81 6.2. Connection-Mode ...................................... 27 82 6.3. Max-Content-Length ................................... 27 83 6.4. Subscription-Mode .................................... 28 84 6.5. Subscription-ID ...................................... 28 85 6.6. Regarding ............................................ 28 86 6.7. Change-Mode .......................................... 29 87 6.8. Cancel-Type .......................................... 29 88 6.9. Duration ............................................. 30 89 6.10. Last-Modified ....................................... 30 90 6.11. Section-ID .......................................... 31 91 6.12. Section-Name ........................................ 31 92 6.13. Location ............................................ 31 93 6.14. Content-Type ........................................ 32 94 6.15. Content-Length ...................................... 32 95 6.16. Auth-State .......................................... 32 96 6.17. SASL-Mechanism ...................................... 32 97 6.18. Message-ID .......................................... 32 98 6.19. Conversation-ID ..................................... 33 99 7. PePP Methods ......................................... 33 100 7.1. LOGIN ................................................ 33 101 7.2. LOGOUT ............................................... 34 102 7.3. SUBSCRIBE ............................................ 35 103 7.4. UNSUBSCRIBE .......................................... 36 104 7.5. REQUESTNOTIFY ........................................ 37 105 7.6. CHANGE ............................................... 38 106 7.7. CANCEL ............................................... 39 107 7.8. FETCH ................................................ 40 108 7.9. NOTIFY ............................................... 41 109 7.10. PULL ................................................ 42 110 7.11. SEND ................................................ 42 111 7.12. RECEIVE ............................................. 43 112 7.13. CALLBACK ............................................ 44 113 7.14. REDIRECT ............................................ 45 114 7.15. SETACL .............................................. 45 115 7.16. GETACL .............................................. 46 116 7.17. CREATESECTION ....................................... 46 117 7.18. DELETESECTION ....................................... 47 118 7.19. PING ................................................ 47 119 7.20. STARTTLS ............................................ 48 120 7.21. CONNECT ............................................. 49 121 8. Status Codes ......................................... 49 122 8.1. 1xx .................................................. 50 123 8.2. 2xx .................................................. 50 124 8.3. 3xx .................................................. 50 125 8.4. 4xx .................................................. 51 126 8.5. 5xx .................................................. 52 127 9. Presence Information Data Format ..................... 53 128 9.1. Overview ............................................. 53 129 9.2. Tag Descriptions ..................................... 54 130 10. Subscribers Information ............................. 57 131 11. Access Control List ................................. 58 132 11.1. Overview ............................................ 58 133 11.2. ACL Functions ....................................... 58 134 11.3. Syntax of ACL ....................................... 59 135 12. Sample Transcripts .................................. 61 136 13. Security Considerations ............................. 65 137 14. Acknowledgments ..................................... 65 138 15. References .......................................... 65 139 16. Authors' Addresses .................................. 66 141 1. Introduction 143 Instant Messaging (IM) and Presence Information (PI) Services have 144 received broad attention as an emerging technology for real-time 145 communication on the Internet. While there are a couple of services 146 already deployed and widely used, each of those is based on its 147 proprietary protocol and users cannot make use of IM Services like 148 e-mails. This is a serious problem to overcome from both the 149 technical and industrial standpoints. To solve the problem, the 150 Instant Messaging and Presence Protocol (IMPP) WG has been formed at 151 IETF, and been working to create an open, interoperable standards for 152 IM/Presence technologies. 154 We at Fujitsu have long been interested in the development of the 155 Internet-wide standards for IM and Presence services. To this end, 156 we have collaborated with other players and contributed to the design 157 of the standards. At the same time, we have been working on an 158 Instant Messaging/Presence protocol called PePP for experimental 159 client and server development. PePP is still a work in progress, and 160 the current implementation is mainly concerned with the single domain 161 utilization. Thus, we have been working to improve PePP to make it 162 satisfy the IMPP requirements [Reqts] based on our interest for the 163 interoperable standard. 165 Our main concerns in the development of PePP are security/privacy and 166 scalability. In particular, as the Presence Service is considered to 167 be fairly privacy sensitive, PePP is designed to have a means for 168 fine privacy control on publishing a variety of Presence Information. 169 For scalability, PePP has some features to avoid the server and 170 connection bottlenecks. 172 This document describes the present version of the extended PePP 173 specification. The authors submits this document as a proposal for 174 the IMPP standardization. Further, we wish to share our ideas in the 175 PePP design with the community to spur further discussion of the 176 development of the standard. We would welcome any comments, 177 suggestions and evaluations on PePP. 179 2. Terminology 181 This document makes use of the vocabulary defined in the IMPP Model 182 and Requirements documents [Model,Reqts]. The capitalized terms such 183 as PRESENTITY, WATCHER, PRESENCE SERVICE are used in the same meaning 184 as defined in [Model,Reqts] unless otherwise stated. Some newly 185 introduced terms are also defined here. 187 A "PePP Server", or just a server is a logical entity which provides 188 the PePP IM/Presence services. A "PePP Client", or just a client is 189 a logical entity which exchanges IMs and/or Presence Information 190 interacting with the servers. Note that, although the IMPP Model 191 document defines several types of ideal clients such as PRESENTITY, 192 WATCHER, SENDER, and INBOX, the PePP client is an entity which may 193 integrate these functions. 195 A "Domain" in the context of PePP is an administrative entity of the 196 IM/Presence services. A user of the IM/Presence services in PePP has 197 an account in a domain, and the user can get the services using one 198 or more clients to connect to the servers in the domain. We call the 199 domain in which a user has an account the "Home Domain" of the user. 201 For a user or the user's client, the "Home Server" is a server in the 202 user's home domain which maintains and publishes Presence Information 203 of the user. As stated in Section 3, the client only has a direct 204 connection with the Home Server, and the user controls her/his 205 Presence Information using the client. 207 A "Resource" in the context of PePP is a data unit in the PePP 208 server, at which Presence Information of a particular PRESENTITY is 209 published so that WATCHERS could access it. Thus, a resource is a 210 unit for controlling and publishing Presence Information. Each 211 resource is managed by the user controlling the PRESENTITY whose 212 Presence Information is published at the resource. The user is 213 called the "Owner" of the resource. 215 A "PePP Address" is an identifier to locate the PePP resource, which 216 is represented by a URI. This is defined in Section 5. 218 If a client tries to access the Presence Information of another user, 219 the user's Home Server is sometimes called the "Target Server" from 220 the viewpoint of the client. 222 A "PePP message" or just a "Message" is the unit of PePP 223 communication, consisting of a structured sequence of octets matching 224 the syntax defined in Section 5. As defined there, a message is a 225 "Request" message or a "Response" message. A "Message Body" is a 226 part of a "Message" as defined in the same definition. Note that a 227 "PePP message" has a different meaning from that of messages when we 228 talk about "Instant Messages". 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119] . 234 3. Protocol Overview 236 3.1. Architecture 238 PePP is designed for scalable and secure Instant Messaging and 239 Presence (IM/P) Services. Because IM/P Services is usually provided 240 as an integrated service, we have designed PePP as a single protocol 241 for both services. 243 The PePP architecture involves two kinds of components; clients and 244 servers. Clients may serve as user agents to the IM/P services, but 245 may also be other software entity to utilize the services. Servers 246 may or may not be different for IM and Presence services, but we 247 assume in this document that a single "Home Server" provides both 248 service for a user. 250 PePP adopts a Client-Server-Server-Client architecture. This means 251 that a client only communicates with its home servers, and only 252 servers can communicate with other servers which are possibly located 253 in different domains. All messages exchanged between a client and a 254 server and between a server and another server are transferred 255 through TCP connections called "PePP connections". A PePP connection 256 has two basic modes; the Client mode and Server mode. The Client 257 mode is for a PePP connection between a client and a server, and the 258 Server mode is for between servers. For descriptive simplicity, we 259 use the terms "PePP Client Connections" and "PePP Server Connections" 260 for PePP connections in the Client and Server mode, respectively. 261 Fig.1 roughly depicts this architecture. 263 PePP Server PePP Server 264 +--------+ +--------+ 265 | HS1 |------------------->| HS2 | 266 | |<-------------------| | 267 +--------+ PePP Server +--------+ 268 ^ ^ ^ CONNECTIONS ^ ^ ^ 269 | | | | | | 270 PePP Client | | | | | | PePP Client 271 CONNECTIONS | | | | | | CONNECTIONS 272 | | | | | | 273 v v v v v v 274 +-----+ +----+ +-----+ +----+ 275 | C1 | | C2 | | C3 | | C4 | 276 +-----+ +----+ +-----+ +----+ 277 PePP Clients PePP Clients 279 Fig.1: PePP Architecture 281 We assume that all the server/server relations could be fully trusted 282 once they are authenticated each other based on appropriate 283 authentication schemes. Thus, when a user in a different domain 284 tries to access your Presence Information, you assume the user is 285 already autheticated by her home domain and trust her identity. 286 Furthermore, as we assume all the notification messages from other 287 servers come through already established PePP Client Connections, the 288 client can trust the authenticity of the notifications without extra 289 authentication. 291 3.2. Model for Presence Service 293 PePP provides a means of fine privacy control of Presence Information 294 publication. 296 3.2.1. Privacy Requirements 298 The IMPP Requirements document [Reqts] stipulates a variety of 299 privacy requirements which IM/Presence services must meet. In 300 addition to "confidentiality" as the most basic requirement, it 301 states that a means for controlling privacy is necessary based on the 302 observation that users are inclined to hide their activities from the 303 public, and further they sometimes want to block a particular user 304 from subscribing to their activity without letting the subscriber 305 know their intention. This is a requirement for so-called "Polite 306 Blocking" (5.1.15 [Reqts]). 308 Another requirement for the Presence Service is that users want to 309 show themselves differently to different watchers (5.2.3 [Reqts]), 310 which is considered as a variation on "Polite Blocking". We call 311 this a requirement for "Personae". 313 These requirements lead our design practice to have multiple pieces 314 of presence information that can be selectively shown to different 315 subscribers. 317 3.2.2. Presence Sections 319 The PePP model considers Presence Information contained in a PePP 320 resource as a collection of several pieces, each of which is called a 321 "presence section". A presence section may contain a status 322 information of a communication means, that of the user, or any other. 323 A presence section can be considered as an embodiment of the notion 324 of a PRESENCE TUPLE, which is defined by the Model document [Model]. 326 The notion of presence sections is intended to be a unit for 327 individual control of publication and filtering. For publication 328 control, PePP allows the user controlling a PRESENTITY to set an 329 access control list per section. For filtering control, PePP allows 330 a WATCHER trying to subscribe to a PePP resource is capable of 331 selecting presence sections to be notified their presence change. 333 Considering the privacy requirements such as "Polite Blocking" and 334 "Personae", there may be a case such that the user controlling a 335 PRESENTITY wants to hide completely which presence sections are shown 336 to the WATCHERS. To realize this in PePP, each presence section has a 337 "section name" as an identifier for the WATCHERS in addition to its 338 unique identifier "section ID". The section ID is used to manipulate 339 the content or control information of the presence section and it is 340 not shown to WATCHERS. Instead, a section name is shown to WATCHERS. 342 An example of a structure of Presence Information (PI) in a PePP 343 resource is shown in Fig.2. Here, an entire PI consists of several 344 sections and each section contains a section ID, a section name, 345 status, note, and an optional communication address. The syntax 346 given here is temporary and the actual syntax of PI is defined in 347 Section 9. 349 +---- section(ID:xxx1, name:user-status) 350 | +--- status(busy) 351 | +--- note("Don't Call until 18:00pm.") 352 | 353 +---- section(ID:xxx2, name:user-status) 354 | +--- status(available) 355 | +--- note() 356 | 357 PI--+---- section(ID:xxx3, name:IM) 358 | +--- status(idle) 359 | +--- address(pepp://pepp.fujitsu.com/suga/iibox) 360 | . +--- note:("Meeting.") 361 | . 362 | . 363 | 364 +---- section(ID:xxxZ, name:email) 365 +--- status(available) 366 +--- address(mailto:suga@sub.fujitsu.com) 367 +--- note:() 369 Fig.2: Presence Information as a set of Presence Sections 371 3.2.3. Section based Access Control 372 Access control in the Presence Service typically controls how to 373 treat requests from WATCHERS. As stated above, PePP assumes the 374 Presence Information consists of multiple presence sections, and each 375 presence section can have different access control list (ACL). 377 When a request for subscription to a resource is received, the 378 presence server evaluates the ACL of the resource to determine which 379 sections should be shown to the WATCHER. Because several sections 380 MAY have the same section name, this mechanism can be used for 381 implementing a feature of "Personae". 383 In the example of Fig.2, the sections "xxx1" and "xxx2" have the same 384 section name "user-status". Consider these sections have ACLs such 385 that the section "xxx1" accepts user A but denies user B, and the 386 section "xxx2" accepts user B but denies user A. When a user A and 387 user B try to subscribe to this resource, user A receives the section 388 "xxx1" as "user-status" and user B receives the section "xxx2" with 389 the same name. 391 A WATCHER may receive several sections with the same name according 392 to the ACCESS RULE, and we do not eliminate this situation in the 393 protocol level. Individual implementation MAY select one of those 394 sections with the same name. 396 Note that ACLs for the requests other than that for subscription is 397 not set for a section, but for a resource. 399 3.2.4. Lease Model of Presence Information 401 PePP adopts the lease model for changing presence information. That 402 is, a PRESENTITY MAY have two pieces of presence information, a lease 403 value and a permanent value, for each section of the presence 404 information. The lease value is associated with its duration value 405 and the client renews the lease value within the duration to keep the 406 lease. Otherwise, the value of the presence section turns back to 407 the permanent value. 409 This feature is preferable because it provides a general solution to 410 handle presence status or availability of various kind of 411 communication means. While availability of some communication means 412 such as IM is subject to unexpected failure or constantly changing 413 communication environment, that of other communication means might 414 always be acquirable from a particular entity. The latter does not 415 have to use the lease value and just change the permanent value of 416 the presence section. The lease model gives flexibility to the 417 control of presence information. 419 3.2.5. Two Modes of Subscription 421 In the case a WATCHER subscribes to a resource publishing Presence 422 Information of a PRESENTITY, the WATCHER usually requires a change 423 notification when the Presence Information is modified. However, a 424 WATCHER sometimes prefers to fetch the Presence Information rather 425 than being notified every time. As PePP has a section based feature 426 of controlling Presence Information, it also provides WATCHERS with a 427 means to choose whether or not to receive notifications for each 428 section. 430 In PePP, a subscriber can receive permitted presence sections within 431 a single subscription to a resource. Moreover, within the 432 subscription, the subscriber can restrict the sections to be notified 433 change notifications. The selected sections are said to be in the 434 Notify mode and the other ones are in the Pull mode. If all the 435 sections are in the Notify mode, the subscription is the one in a 436 usual sense and is called a Notify mode subscription. In a Pull 437 mode, the client fetches the interested presence section when it 438 wants. It is desirable when the subscriber wants to reduce the 439 frequency of notification, for instance, in the case the user has a 440 PePP client on a cellular phone device which charges per packet. This 441 feature of PePP also realizes so called Selective Subscription. 443 The subscriber in the Pull mode subscription can be considered as a 444 notion of FETCHER defined by the IMPP Model document [Model]. 445 Therefore, the notion of subscribers in PePP coincides that of 446 WATCHERS of the Model document, and the Subscribers Information (see 447 Section 10) corresponds to the WATCHER INFORMATION in it. This is so 448 designed because we believe that a WATCHER should be required to 449 declare the interest on the PRESENTITY whether she/he wants to get 450 notifications or not. 452 The Pull mode subscription may possibly cause a heavy load on the 453 server. So, the server SHOULD be able to disallow it based on its 454 policy. 456 3.3. PePP Connections 458 All PePP connections are TCP connections. We adopted TCP because it 459 is widely used as a reliable transport on the Internet and we believe 460 all the messages in PePP, not only IMs but also changes and 461 notifications of Presence Information, must be safely transported. 462 It is also favorable in the existence of firewalls because UDP 463 datagrams are not usually permitted to come into through firewalls. 465 As stated above, PePP mandates two kinds of connections; PePP client 466 connections and PePP server connections. Moreover, as an OPTIONAL 467 specification, we propose a mechanism to establish a virtually direct 468 connection between clients for the sake of the end-to-end security. 470 3.3.1. Client Connections 472 A PePP client connection is a TCP connection between a client and its 473 Home Server (HS). It is established only by the requests from 474 clients. Clients can create more than one PePP connections if 475 necessary. However, the first connection between the client and 476 server plays a designated role as a "main" connection, and it is 477 expected to be persistent during the service. Other connections are 478 called "backup" connections. 480 (a) Establishing a Connection 482 On establishing a PePP client connection, a client opens a TCP 483 connection to its HS and issues a LOGIN request message to the HS to 484 start an authentication process. In the LOGIN request, the client 485 MUST specify information about the authentication process (AUTH-STATE 486 header), a connection mode (CONNECTION-MODE header), and MAY specify 487 the maximum size of a message body it wishes to receive (MAX- 488 CONTENT-LENGTH header). The client MUST specify "client" as the 489 value of the Connection-Mode header field. 491 PePP connections use SASL [SASL] as an authentication framework. The 492 client and server negotiate the SASL Mechanism to be used by the 493 SASL-Mechanism header field. SASL Mechanisms supported in the PePP 494 LOGIN process are CRAM-MD5 [CRAM-MD5], EXTERNAL [SASL], and PLAIN 495 [SASL-PLAIN]. 497 1) CRAM-MD5 - It can always be specified. 498 2) EXTERNAL - It uses TLS client authentication, and can be specified 499 only if TLS client authentication is supported [TLS]. 500 3) PLAIN - It can be specified only if TLS encryption is enabled. 502 The authentication process MAY be completed in a sequence of LOGIN 503 requests and their responses. If the process terminated successfully, 504 the last response MUST contain the fields specifying the connection 505 ID (CONNECTION-ID header) and the MAX-CONTENT-LENGTH header field. 506 The server MAY overwrite the value of the MAX-CONTENT-LENGTH 507 specified by the client. 509 If a client wishes a secure transport, it MAY issue a STARTTLS 510 request prior to the LOGIN request in order to upgrade the 511 established TCP connection to a TLS enabled secure one. The TLS 512 layer simply encrypts the whole PePP messages on the top of a TCP 513 connection, and provides secure communication channels between 514 connection peers. 516 (b) PePP Messages 518 Once the PePP connection is established, it is used to send PePP 519 request and response messages, which have similar syntax to HTTP 520 messages, for the Presence and IM services. Like HTTP, a PePP 521 request message generates a corresponding single response message. 522 However, unlike HTTP, the PePP client connection can be used by both 523 of the client and server to send the PePP request messages in both 524 directions. 526 Because the "main" client connection is supposed to be persistent, 527 either ends of the connection MUST send PING requests periodically in 528 order to confirm the other is alive. 530 A PePP connection allows request pipelining, i.e. a client can send 531 another request to the same connection before receiving the response 532 to the previous request. Moreover, PePP allows the responses can be 533 received in the different order from that of requests in order to 534 avoid the server bottleneck caused by the processing overhead. To 535 this end, every PePP messages MUST contain a Request-ID which is a 536 unique identifier of each request message. The response message MUST 537 contain the same Request-ID as that of the corresnponding request 538 message to make correspondence between requests and responses. 540 In order to distinguish a PePP message from the subsequent ones, a 541 PePP message MAY contain a Content-Length header field. If a PePP 542 message has a Content-Length header, its value MUST match the exact 543 data size of the message body. 545 In the client connections, all the PePP requests defined in this 546 document can be issued. 548 (c) Closing a Connection 550 In order to close a PePP connection, a LOGOUT request MAY be sent by 551 either ends of the connection. When a client or server receives a 552 LOGOUT request, it MUST send 200 OK response if it is not to send 553 another request to the connection peer. A client or server which has 554 issued a LOGOUT request SHOULD wait an OK response before closing the 555 connection. 557 A client or server MAY close the connection without issuing a LOGOUT 558 request in the case it encounters an abnormal status. For instance, 559 the connection MAY be closed without any notice in the following 560 cases. 562 1) The message border in the connection is broken because 563 of a wrong Content-Length specified. 564 2) The size of the data currently receiving has exceeded the 565 Max-Content-Length of the connection. 566 3) Time-out. 568 (d) Backup Connections 570 A client MAY request to establish more than one connections as 571 "backups" if necessary. A backup connection is established by the 572 same procedure as the main connection. It is typically considered 573 necessary when the client is to send or receive data larger than the 574 Max-Content-Length value of the main connection. The purpose of 575 backup connections is to avoid latency caused by sending huge data 576 through relatively slow connections. 578 A client MUST request to establish a backup connection when it is to 579 send a larger message body than the Max-Content-Length values of 580 existing connections. If the data size is less than one of the Max- 581 Content-Length values of the existing connections, the client SHOULD 582 NOT request a new connection. A LOGIN request for a backup connection 583 MUST have a Backup-For header field specifying the connection ID of 584 the main connection. 586 Although a server cannot request to open a new client connection, the 587 server can issue a CALLBACK request through the main connection to 588 ask the client to open a new connection. The CALLBACK request MAY 589 contain information of the new address to be connected. If the 590 server sends a message with a content larger than the Max-Content- 591 Length values of existing connections, it MUST send a CALLBACK 592 request to the main connection and wait for a new connection. The 593 client MAY refuse the CALLBACK request. 595 Backup connections MAY be closed by either end of the connection if 596 it is considered no more necessary. Backup connection SHOULD be 597 closed by LOGOUT requests. 599 3.3.2. Server Connections 601 A PePP connection in the "server" mode, or a PePP server connection, 602 is a TCP connection between servers. We use a term "Target Server" 603 in contrast with "Home Server" to designate the remote server which 604 the client cannot connect directly. 606 If the Home Server of a client receives requests destined for another 607 Target Server, it MUST establish a PePP server connection with the 608 Target Server and forward the request to it. Unlike PePP client 609 connections, only the initiator of the connection can issue requests 610 in general and it MAY close the connection if it is judged not to be 611 necessary any more. 613 (a) Establishing a Connection 615 When a server is to establish a PePP server connection, it MUST try 616 to look up a DNS SRV record for the "impp" service on the "tcp" 617 protocol prior to looking for an A record to locate another server. 619 After locating the other server, the initiating server opens a TCP 620 connection to the other and sends a LOGIN request to start 621 authentication process. In the LOGIN request, the initiating server 622 specifies information about the authentication process, a connection 623 mode, and the maximum content size it wishes to receive. For the 624 server connection, the value "server" MUST be specified as a value of 625 Connection-Mode header field. 627 The allowed SASL Mechanisms for PePP server connections are CRAM-MD5 628 [CRAM-MD5] and EXTERNAL [SASL]. PLAIN is disallowed because it seems 629 unnecessary if the servers could authenticate each other by the TLS 630 mutual authentication, and this is very likely. 632 1) EXTERNAL - It uses TLS client authentication, and can be specified 633 only if TLS client authentication is supported. 634 2) CRAM-MD5 - It MAY be accepted depending on the server policy. 636 CRAM-MD5 is only for an experimental use because sharing the secret 637 passwords between different domains seems to be undesirable. It is 638 STRONGLY RECOMMENDED to upgrading to a secure transport by issuing a 639 STARTTLS request prior to the LOGIN request. 641 (b) PePP Messages 643 A PePP server connection is mainly used to exchange request and 644 response messages between different domains. Unlike PePP client 645 connections, server connections are one-way connections, i.e. only 646 the initiating server of the connection can issue request messages 647 except for a LOGOUT request. 649 Like client connections, every PePP messages MUST contain a Request- 650 ID which is a unique identifier of each request message, and every 651 PePP messages MUST have a Content-Length header field whose value is 652 the exact data size of its message-body. 654 In the server connection, request messages for administration use is 655 not allowed. Only the following request messages can be issued: 656 LOGIN, LOGOUT, SUBSCRIBE, UNSUBSCRIBE, REQUESTNOTIFY, NOTIFY, PULL, 657 SEND, PING, STARTTLS, CONNECT. 659 (c) Closing a Connection 661 Like PePP client connections, the either side of the connection MAY 662 issue a LOGOUT request MAY to close it. When one of the connection 663 peers receives a LOGOUT request, it MUST send '200 OK' response if it 664 is not to send another request to the connection. The connection 665 peer which has issued a LOGOUT request SHOULD wait an OK response 666 before closing the connection. 668 Same as the case of client connections, each connection peer MAY 669 close the connection without issuing a LOGOUT request in some 670 abnormal status. 672 (d) Backup Connections 674 A server MAY request to establish more than one connection to the 675 same server at any time if necessary. So, a server MAY have one or 676 more connections with the same Max-Content-Length value. 678 As we may assume a PePP server can accept a LOGIN request from other 679 servers, we do not distinguish "backup" connection from the "main" 680 one. They are independent connections. 682 3.3.3. Direct Connections 684 PePP has a mechanism to establish a virtually direct connection 685 between clients. This is an OPTIONAL feature in PePP. 687 A "Direct Connection" is a PePP Connection in the "direct" mode. The 688 Direct Connection is the virtual connection between the clients and 689 implemented using the Client Connection and the Server Connection. 691 The Direct Connection is designed for providing the end-to-end 692 security to PePP, especially a private conversation channel for IMs 693 between clients in order not to be tampered by even the 694 administrators of the servers. 696 (a) Establishing a Connection 697 When the client is going to establish to Direct Connection, first of 698 all, the initiator client opens a new Client connection to its home 699 server, and issues a LOGIN request to identify itself. Then, the 700 initiator issues a CONNECT request, which asks the Home Server to 701 provide a "raw" TCP socket over the current connection. 703 The home server holds this TCP connection and opens another TCP 704 connection to the Target Server. The way for discovering the Target 705 Server is same as Server Connection described above. 707 After LOGIN, the Home Server issues CONNECT request to ask "raw" TCP 708 connection to the Target Server. Then, the Target Server issues a 709 CALLBACK request to one of the 'receiver' clients which has asked IM 710 delivery by the RECEIVE request (See Section 3.5). 712 Having established a brand-new TCP connection with the client as a 713 result of the CALLBACK request, the Target Server responds to the 714 Home Server '200 OK' response, and the Home Server also responds '200 715 OK' response to the initiator client. 717 Finally, the initiator client issues STARTTLS command, which is 718 directly sent to the target client, and they can send and receive 719 messages securely over this virtual connection. 721 (b) PePP messages 723 The Direct Connection behaves like as a Client Connection does, but 724 only SEND, PING and LOGOUT requests are allowed. 726 (c) Closing a Connection 728 Both of the clients can issue a LOGOUT request to terminate the 729 Direct Connection. The client which has issued a LOGOUT request 730 SHOULD wait to receive the response. 732 (d) Backup Connections 734 Because the separate Direct Connections MAY be established between 735 the same two clients, backup connections for the direct connection 736 will not be necessary. 738 3.4. Subscription Model 740 As stated in the previous sections, a PePP client MUST subscribe to 741 Presence Information in the Target Server via its Home Server. The 742 Home Server and Target Server are generally distinct servers while 743 they might happen to coincide (Fig. 3). If a client has a 744 subscription to a resource at a Target Server, the subscription 745 information is stored at the client, its Home Server, and the Target 746 Server. 748 This subsection describes the behavior of these components in 749 relation with Presence Information subscription. 751 Client -------- Home Server (HS) -------- Target Server (TS) 752 No Expiration Expiration 754 Fig.3: Subscription Model 756 3.4.1. Behavior of Clients 758 The PePP client connection is expected to be persistent until the 759 client sends LOGOUT to the HS or some failure occurs. If the 760 connection is in an abnormal status, for instance the response of 761 PING request cannot be received, the client SHOULD disconnect the 762 connection and try to reconnect in a certain amount of time and 763 reissue all the SUBSCRIBE requests. 765 3.4.2. Behavior of Home Servers 767 Because a PePP server connection is not necessarily persistent, the 768 servers on the connection peers cannot detect another one's failure 769 by watching the connection. As a solution to this problem, PePP 770 utilizes the expiration model for subscription. Thus, a subscription 771 will expire unless it is renewed by another subscription request 772 within a certain amount of the associated duration time. 774 A Home Server MUST store and manage all the subscription information 775 of its clients possibly to the other servers. More precisely, a HS 776 MUST watch all the requests from the clients to subscribe or 777 unsubscribe resources and all the cancel notification from the TSs, 778 and store the up-to-date information about each subscription, which 779 consists of the target resource, subscription ID, duration, and the 780 client connection ID. Moreover, in order to save the traffic on the 781 client connections, the HS MUST renew all its clients' subscriptions 782 regularly on behalf of the clients. 784 If the HS detects a client connection has been lost, it MUST send 785 requests to Target Servers to unsubscribe all the current 786 subscriptions from the relevant client. 788 The duration for subscription should be considerably long in order to 789 reduce the traffic of renew messages. 791 3.4.3. Behavior of Target Servers 793 The Target Servers MUST keep and manage the current subscription 794 information in order to issue change notifications about the target 795 resources. Because subscriptions are subject to expiration as 796 stated above, a server SHOULD remove the subscription information 797 unless it is renewed within a certain amount of duration time. 799 When the TS detects an error of the notification requests it has 800 issued, the subscription information which caused the failed 801 notification MUST be removed. When the server removes some 802 subscription information, it MUST send a notification to the relevant 803 subscriber asking her/him to retry subscription. 805 3.5. Instant Messaging Service 807 3.5.1. Basic Architecture 809 As PePP was originally developed for the Presence Service which 810 requires minute control of presence publication, its basic Instant 811 Messaging (IM) feature is designed similar to PePP's subscription and 812 notification mechanism. 814 A user's INSTANT INBOX in PePP is a PePP resource to be addressed 815 when an IM is sent to the user. The receiver's client issues a 816 RECEIVE request to the INBOX resource to register itself as a 817 destination to forward the IMs it receives. Then the client 818 connection is registered as a 'receiver' connection. An IM is 819 delivered by SEND requests. When the INSTANT INBOX receives an IM, 820 the server issues a new SEND request to forward the IM to the 821 'receiver' connection (see Fig.4). 823 In PePP, the INBOX address of a receiver is not uniquely determined 824 by her/his PePP address. Actually, the INBOX address may be same as 825 the receiver's PePP address and may be different. Thus, the INBOX 826 address MUST be contained in the user's presence information. The 827 PePP client SHOULD send IMs for this address in order to be received 828 by the intended recipient unless other address has been specified in 829 an out-of-band manner. 831 PePP Server PePP Server 832 +---------+ +-------+ 833 |SENDER HS|------------------>| INBOX | 834 +---------+ SEND +-------+ 835 ^ ^ | 836 | | | 837 |SEND RECEIVE| |SEND 838 | | | 839 | | v 840 +---------+ +--------+ 841 |SENDER UA| |INBOX UA| 842 +---------+ +--------+ 843 Sender Receiver 845 Fig.4: Basic Architecture of PePP IM Service 847 3.5.2. IM Conversation 849 Although an IM can be used as a single one-way message, the typical 850 usage in the IM Service is a conversational one, i.e. two or more 851 users exchange IMs in a 'chat' style. When a user wants to talk with 852 a buddy, she directs an IM application to open a window for 853 conversation, and uses the window for a talk with the buddy. She may 854 open several conversation windows to talk with some of her buddies at 855 the same time. 857 To realize this, each SEND message MUST have a Conversation-ID header 858 field to identify the conversation it belongs. The Conversation-ID 859 field MUST have a globally unique value like a Message-ID, which is 860 also a globally unique identifier of the SEND message given by the 861 client. The initial client to start the conversation thread with 862 others MUST assign a value of Conversation-ID. It MAY reuse its 863 Message-ID as the Conversation-ID. 865 3.5.3. Multiparty Conversation 867 While PePP's basic IM mechanism is for one-to-one conversation, it 868 can be extended to a simple multiparty IM conversation. If a 869 participant of an already established IM conversation wants somebody 870 to join, he send a SEND request message to the user with the current 871 Conversation ID and the Reply-To header whose value is a list of 872 recipients. Then the invited user joins the conversation by sending 873 his message with the specified Conversation ID to all the recipients 874 described in the Reply-To field. 876 Obviously, this method of multiparty conversation has two problems. 878 One is a scalability problem if the number of participants increases, 879 and the other is it does not provide a means to delete the recipient 880 when one participant quits the conversation. But, we think usual IM 881 conversation is shared by very small number of users, and it will be 882 closed in a short time. It is expected that it would not cause so 883 much practical problems. 885 3.6. Character and Content Encoding 887 For character encodings, PePP clients MUST accept the UTF-8 encoding 888 of the ISO/IEC 10646 (UCS-4) character set, and MUST NOT cause errors 889 by handling them. The user agent MUST display the content of 890 presence information, instant messages, and other messages for at 891 least US-ASCII part of UTF-8 encoding. 893 Content or character encoding method is declared in 'charset' 894 attribute in Content-Type header as in the example below. 896 Content-Type: text/plain; charset=UTF-8 898 For the content type which has 'charset' as its attribute, specifying 899 encoding method in 'charset' is STRONGLY RECOMMENDED. If the content 900 type is text/xml, character encoding MAY be specified in the XML 901 declaration as in the following example. In this case, the XML 902 declaration is used. 904 906 PePP servers and proxies MUST NOT cause an error for arbitrary 907 content of presence information and instant messages in any content 908 encodings. PePP servers and proxies MUST deliver the content of 909 presence information and instant messages to the targets. 911 4. Considerations Regarding IMPP Requirements 913 The IMPP Requirements document [Reqts] describes that an 914 interoperable and widely-deployable standard protocol for IM/Presence 915 must be scalable, secure, and appropriate for use with wireless 916 devices. This section contains the considerations about PePP's 917 strength and weakness for these criteria. Additionally, we give a 918 note on the requirement for the separability of IM and Presence 919 services. 921 4.1. Scalability 923 There are many aspects to scalability issues. We have considered the 924 following features in the design of PePP; 925 (1) the option to distribute server load over multiple servers, 926 (2) the avoidance of processing bottlenecks where a delay in 927 processing one message blocks other messages. 928 (3) the avoidance of connection bottlenecks where a single 929 huge message blocks many smaller messages. 931 As a means to reduce the load of the servers, PePP allows any command 932 to be redirected to an alternate server. This enables various 933 strategies for dynamically allocating server resources and load 934 balancing. 936 To avoid the processing bottlenecks, PePP allows the responses to be 937 received in the different order from that of requests by utilizing 938 the Request ID in the messages so that the response can be matched 939 with the corresponding request. 941 There are two typical solutions to avoid the connection bottlenecks, 942 data chunking/interleaving on a single connection, or the creation of 943 multiple parallel connections. PePP has adopted the latter because 944 it seems reasonable to open a new connection to send a huge data 945 during an IM conversation. Another reason is that command-level 946 chunking/interleaving is difficult in PePP as its command syntax is 947 based on HTTP. 949 4.2. Security 951 We have adopted the following security model for the IM/Presence 952 services in PePP. 954 4.2.1. Trust model 956 We assume the network is not trustworthy at all. 958 Once authenticated each other, client-server and server-server 959 relations are considered to be fully trustworthy. That is, the 960 servers are trustworthy in the sense that; 961 * the servers disclose presence information and/or IMs to 962 authorized parties only. 963 * the servers distribute presence information and/or IMs 964 uncorrupted. 965 * the IM servers relay IMs only from authorized senders. 967 However, even though a user could trust the home server and servers 968 are mutually trustworthy, other servers may be less trustworthy for 969 the user. For instance, the other domain might not support any 970 transport security for the Client connections. The current 971 specification of PePP does not have a mechanism of knowing the 972 security level of other domains. 974 4.2.2. Transport Security 976 As we cannot assume the network is trustworthy, IM/Presence services 977 require transport security to prevent tapping and tampering of 978 messages. PePP adopts TLS for this purpose. The Server Connections 979 are STRONGLY RECOMMENDED to be encrypted using TLS. 981 4.2.3. Confidentiality of Presence Information 983 Presence information may be shared with an indefinitely large set of 984 WATCHERS. Thus, end-to-end content encryption for each subscriber is 985 too costly and impractical. If transport security is assumed, it is 986 reasonable to provide no further content encryption. We believe 987 access control preferences for presence information to provide an 988 acceptable level of privacy control in PePP. 990 4.2.4. Integrity of Presence Information 992 Under the trust model stated above, we trust all servers to not 993 corrupt or alter presence information. Thus, PePP does not provide 994 any additional mechanism to protect the integrity of presence 995 information beyond the TLS transport security. 997 Obviously, this is a weakness of PePP. We cannot say there is no 998 more threat of the "Man-in-the-Middle" atack. To avoid this, we have 999 to provide a means to put a digital signature on presence 1000 information. Because presence information in PePP is a set of 1001 individual sections, a digital signature is needed to each sections 1002 individually but this might be costly. So, it might be desirable to 1003 merge some sections together and sign on the merged sections. 1005 Even if digital signature is available, there is another threat of 1006 the replay attack. But, if a timestamp could be included at the time 1007 of digital signature, it would be helpful to avoid the apparent 1008 attacks while this is not a perfect solution. 1010 4.2.5. Confidentiality of IM 1011 As PePP provides a basic functionality for transport security using 1012 TLS, IMs can be securely transported on the wire. However, only this 1013 does not provide the end-to-end security. For instance, a malicious 1014 server administrator can read the content of IM conversation. 1016 To provide the end-to-end security, PePP has an optional feature to 1017 establish a virtually direct connection between the clients which can 1018 be encrypted by TLS entirely. This assumes that the both clients 1019 have their digital certificates for their identities. Once such a 1020 direct connection is established, the clients can talk completely 1021 securely without so much overhead. 1023 We once considered the adoption of the message-level encryption 1024 standards such as S/MIME or OpenPGP. However, these standards impose 1025 the clients too much overhead, and seems to be impractical especially 1026 for the mobile devices. Moreover, if we assume transport security, 1027 this also implies the inefficiency of double-encryption. 1029 4.2.6. Access Control 1031 PePP's section mechanism provides fine-grained access control over 1032 published presence information. A publisher can specify exactly which 1033 sections any particular party will see. For example, some WATCHERs 1034 can be shown IM presence but not shown cell phone presence. 1036 Moreover, by using the same section name for different sections, 1037 WATCHERs can be show different values for the same fields. We call 1038 this feature "personae", and think it is very useful for privacy- 1039 sensitive applications. 1041 4.3. Wireless 1043 Wireless devices usually have limited computing and communication 1044 resources. As a result, more concise protocols are better and binary 1045 formats can be most efficient. However, PePP has adopted text-based 1046 formats for readability, extensibility, and ease of debugging. 1048 PePP's section-based presence format offers opportunities to reduce 1049 the size of tranferred content. For example, PePP allows selective 1050 subscription, which allows SUBSCRIBERs to receive only an interesting 1051 subset of all presence information sections. We think this 1052 selectivity is especially desirable for a wireless environment. 1054 4.4. Separability of Services 1055 PePP is designed as an integrated protocol for both IM and Presence 1056 Services. However, the requirements document seems to require that 1057 the protocol MUST allow separation of these services; 1059 2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available 1060 independent of whether an INSTANT MESSAGE SERVICE is available, 1061 and vice-versa. 1063 Although PePP is a single protocol for IM and Presence Services, we 1064 think it allows the two services to be provided separately. As PePP 1065 is originally designed for Presence Service, PePP is applicable as a 1066 protocol for the Presence Service without IM. A presence section is 1067 generic for various communication means other than IMs, and a section 1068 for IM contains a URI as an IM address. This feature allows IM 1069 Service to be a distinct one from the Presence Service. 1071 If we could disable the functions in PePP for Presence Service, it 1072 seems to be able to provide IM Service only. More concretely, 1073 functionality for establishing the PePP connections (LOGIN, STARTTLS, 1074 CALLBACK, CONNECT, and LOGOUT) and that for IM exchange (SEND and 1075 RECEIVE) seem to be sufficient to provide the IM Service in PePP. We 1076 assume that the IM addresses are available in an out-of-band manner. 1078 5. PePP Messages 1080 5.1. Message Overview 1082 The message format for the PePP protocol basically follows the 1083 formats for HTTP/1.1 [HTTP1.1]. Thus, a message consists of a start 1084 line, zero or more header fields, and possibly a message-body. A 1085 start line is either a request line or response line. A request line 1086 contains a PePP command, a PePP Resource as a target resource, a 1087 Request ID of the request itself, and a PePP Version identifier. 1089 PePP command details are described in Section 7. 1091 Headers are defined in Section 6. Headers defined here MAY appear at 1092 most once in a PePP message unless otherwise stated. Headers in PePP 1093 messages which are not defined in this specification MUST be ignored 1094 except for the case of SEND messages. 1096 A message-body conveys a content of presence information and instant 1097 messages. We use XML as a syntactic framework for the data format of 1098 presence information. MIME format is used when multiple presence 1099 sections are packed into a single message. MIME is also used for 1100 IMs. 1102 The PePP Version identifier used for PePP messages in this spec is 1103 "PePP/0.5" at present. 1105 5.2. PePP Addresses 1107 A PePP Resource is represented as a form similar to the HTTP URL 1108 defined in HTTP/1.1 [HTTP1.1]. That URI is called the PePP Address 1109 of the resource. The same namespace is used for both Presence 1110 Service and IM Service in PePP. Because PePP is designed for PePP 1111 services, we use "pepp" for the protocol scheme name in the URL 1112 namespace. The syntax of PePP Addresses is defined as follows. 1114 PePP-Address = "pepp:" "//" host [":"port]] abs_path 1116 host = 1119 port = 1*DIGIT 1121 abs_path = 1123 In the PePP addresses, the local namespace can be extended utilizing 1124 paths like HTTP URL by the domain administrator or the owner of the 1125 resources for Presence Information or the INBOX address for IMs. 1127 PePP utilizes the PePP Address of the user's top resource as an 1128 identifier of the user, which is used in the From header of a PePP 1129 request. 1131 5.3. Message Syntax 1133 The format of PePP messages is defined as follows, which is described 1134 in an augmented Backus-Naur Form (BNF) used in [HTTP1.1]. 1136 PePP-Message = PePP-Request | PePP-Response 1137 PePP-Request = PePP-Command SP Request-ID SP PePP-Version CRLF 1138 *(( PePP-Header ) CRLF) 1139 CRLF 1140 [message-body] 1142 PePP-Response = PePP-Status-Line 1143 *(( PePP-Header ) CRLF) 1144 CRLF 1145 [message-body] 1147 PePP-Status-Line = PePP-Version SP Request-ID SP Status-Code SP 1148 Reason-Phrase CRLF 1150 PePP-Version = "PePP" "/" 1*DIGIT "." 1*DIGIT 1152 Request-ID = token 1154 PePP-Command = LOGIN ; section 7.1 1155 | LOGOUT ; section 7.2 1156 | SUBSCRIBE ; section 7.3 1157 | UNSUBSCRIBE ; section 7.4 1158 | REQUESTNOTIFY ; section 7.5 1159 | CHANGE ; section 7.6 1160 | CANCEL ; section 7.7 1161 | FETCH ; section 7.8 1162 | NOTIFY ; section 7.9 1163 | PULL ; section 7.10 1164 | SEND ; section 7.11 1165 | RECEIVE ; section 7.12 1166 | CALLBACK ; section 7.13 1167 | REDIRECT ; section 7.14 1168 | SETACL ; section 7.15 1169 | GETACL ; section 7.16 1170 | CREATESECTION ; section 7.17 1171 | DELETESECTION ; section 7.18 1172 | PING ; section 7.19 1173 | STARTTLS ; section 7.20 1174 | CONNECT ; section 7.21 1176 PePP-Header = From ; section 6.1 1177 | Connection-Mode ; section 6.2 1178 | Max-Content-Length ; section 6.3 1179 | Subscription-Mode ; section 6.4 1180 | Subscription-ID ; section 6.5 1181 | Regarding ; section 6.6 1182 | Change-Mode ; section 6.7 1183 | Cancel-Type ; section 6.8 1184 | Duration ; section 6.9 1185 | Last-Modified ; section 6.10 1186 | Section-ID ; section 6.11 1187 | Section-Name ; section 6.12 1188 | Location ; section 6.13 1189 | Content-Type ; section 6.14 1190 | Content-Length ; section 6.15 1191 | Auth-State ; section 6.16 1192 | SASL-Mechanism ; section 6.17 1193 | Message-ID ; section 6.18 1194 | Conversation-ID ; section 6.19 1196 Status-Code and Reason-Phrase are described in Section 8. 1198 6. PePP Headers 1200 6.1. From 1202 The From header field contains the PePP address of the requesting 1203 entity. The From header MUST be included in all requests transported 1204 through the PePP server connections. If a server receives a request 1205 without the From header through one of a server connection, the 1206 server MUST return 400 Bad Request error. Requests only used in PePP 1207 client connections MAY not have this header. 1209 From = "From" ":" PePP-Address 1211 6.2. Connection-Mode 1213 The Connection-Mode header field is included in LOGIN requests to 1214 indicate the mode of the connection. The value can take one of the 1215 two string tokens. 1217 Connection-Mode = "Connection-Mode" ":" ("server" | "client" | 1218 "direct") 1220 o server 1221 This value indicates the connection is requested in the "server" 1222 mode. 1224 o client 1225 This value indicates the connection is requested in the "client" 1226 mode. 1228 6.3. Max-Content-Length 1230 The Max-Content-Length header field is included in LOGIN 1231 requests/responses and CALLBACK requests and indicates the size of an 1232 acceptable message body by the connection in decimal number of 1233 octets. The syntax is defined the same as in HTTP/1.1 [HTTP1.1]. 1235 Max-Content-Length = "Max-Content-Length" ":" 1*DIGIT 1237 6.4. Subscription-Mode 1239 The Subscription-Mode header field which appears in the SUBSCRIBE 1240 request specifies the mode of the requesting subscription. The value 1241 can take one of the three; notify, pull, renew. 1243 Subscription-Mode = "Subscription-Mode" ":" ("notify" | "pull" | 1244 "renew") 1246 o notify 1247 If the client requests to be notified when a change occurs in the 1248 target resource, this mode is specified. This is default. 1250 o pull 1251 The client tells the server that it would not like any changes to 1252 be notified. When the client wants to get the content of the 1253 resource in the Pull mode, it sends a PULL request to the server 1254 explicitly. 1256 o renew 1257 This mode is used in order to renew the subscription specified by 1258 the Subscription-ID. The response caused by the subscription 1259 request with this mode MUST NOT have a message body. 1261 6.5. Subscription-ID 1263 The Subscription-ID header is used to specify the identifier of the 1264 subscription of concern in the request or the response. The server 1265 MUST specify this header field and value in the response to the 1266 SUBSCRIBE request. The client uses this value in the subsequent 1267 request to specify the subscription. 1269 Subscription-ID = "Subscription-ID" ":" token 1271 The value of Subscription-ID MUST be uniquely assigned at least 1272 modulo PePP resource. 1274 6.6. Regarding 1276 The Regarding header is used in the SUBSCRIBE, FETCH or NOTIFY 1277 requests. The value can take one of two string tokens. 1279 Regarding = "Regarding" ":" ("value" | "control" ) 1281 If the Regarding header field appears in SUBSCRIBE or NOTIFY 1282 requests, it designates the kind of the subscription or notification. 1283 The "value" and "control" in this field specifies the subscription or 1284 notification is regarding the Presence Information and Subscribers 1285 Information respectively. If the Regarding header appears in a FETCH 1286 request, it means the kind of information the request tries to fetch. 1287 The meaning of the two values are same as in SUBSCRIBE and NOTIFY 1288 requests. The default value is "value". 1290 6.7. Change-Mode 1292 The Change-Mode header is used in the CHANGE request to specify the 1293 behavior of the request. The value can take one of four string 1294 tokens. 1296 Change-Mode = "Change-Mode" ":" ("lease" | "permanent" | "renew" | 1297 "revert" ) 1299 o lease 1300 This mode is used to set or change the lease value of the presence 1301 section. It resets the lease timer of the section, and causes to 1302 send change notifications to the subscribers. 1304 o permenent 1305 This mode is used to set or change the permanent value of the 1306 presence section. If there is no lease value, it causes to send 1307 change notifications to the subscribers. 1309 o renew 1310 This mode is used to renew the lease value of the presence 1311 section. It resets the lease timer of the section, but does not 1312 cause any notifications. 1314 o revert 1315 This mode is used to remove the lease value of the presence 1316 section and revert to its permanent value. It causes to send 1317 change notifications to the subscribers. 1319 6.8. Cancel-Type 1321 The Cancel-Type header is used in CANCEL requests and the NOTIFY 1322 requests caused by the CANCEL requests. 1324 Cancel-Type = "Cancel-Type" ":" ("cancel" | "retry") 1326 When a subscription is CANCELed, a NOTIFY request is issued to the 1327 WATCHERS in order to specify the expected action of the receiver 1328 client. If the server wants to direct the WATCHER client to retry 1329 subscription, the "retry" value MUST be set in the Cancel-Type header 1330 field. If the server wants to state the client not to retry to 1331 subscribe, the "cancel" value MUST be set in this field. The client 1332 SHOULD NOT subscribe to the same resource if the subscription was 1333 canceled with the value "cancel" in the Cancel-Type header. 1335 The Cancel-Type header is used in the CANCEL requests to specify the 1336 Cancel-Type header in the NOTIFY request caused by it. If this 1337 header is omitted in the CANCEL request, the value of "cancel" is 1338 used. 1340 6.9. Duration 1342 The Duration header field specifies a lifetime of the lease value of 1343 the presence section in an integer second count if it is used in a 1344 CHANGE request or its response. The response for the CHANGE request 1345 with the Change-Mode 'lease' and 'renew' MUST contain the Duration 1346 header field. Such a CHANGE request MAY contain the Duration header 1347 as the client's request, but the server MAY ignore the value based on 1348 its policy. The client MUST use the specified value in the response 1349 as the duration for the presence section. 1351 The Duration header is also used in SUBSCRIBE request issued by the 1352 Home Server to specify a lifetime of the subscription. The response 1353 for the SUBSCRIBE request MUST contain the Duration header that 1354 specifies the duration of the subscription. The Home Server MUST use 1355 the specified duration value in the response even if it specified a 1356 different value in the SUBSCRIBE request. 1358 Duration = "Duration" ":" 1*DIGIT 1360 6.10. Last-Modified 1362 The Last-Modified header field specifies the date/time of the latest 1363 change of the transported content. It is specified by the server. 1365 For Presence Information, each presence section has a last-modified 1366 value, and the value is changed in the following four cases; a) a 1367 CHANGE request changes the lease value, b) the lease value expires 1368 and the value changes to the permanent value, c) the permanent value 1369 is changed when the lease value is not set, d) the lease value is 1370 removed. The generated NOTIFY request message MUST have the Last- 1371 Modified header field containing this value. 1373 The response of a SUBSCRIBE or FETCH request MAY have MIME Multipart 1374 content with the multiple presence sections. In this case, the 1375 Last-Modified header MUST appear as one of the MIME-part-headers of 1376 each body part of the multipart entity. 1378 The date/time format is specified as follows. It is one of the 1379 format specified in ISO 8601 [ISO8601]. 1381 Last-Modified = "Last-Modified" ":" date "T" time "Z" 1383 date = 4DIGIT "-" 2DIGIT "-" 2DIGIT 1384 ; year-month-day 1385 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 1386 ; hour:minute:second (00:00:00 - 23:59:59) 1388 Example: 1999-12-08T18:05:23Z 1390 6.11. Section-ID 1392 The Section-ID header field specifies the unique identifier of the 1393 presence section. When a presence section is to be created, the 1394 CREATESECTION request is issued by the client and the request MUST 1395 include this header. Its value is created by the client, and the 1396 uniqueness of the value is checked by the server. The CHANGE and 1397 DELETESECTION requests MUST contain this header as well. This header 1398 MAY also appear in the FETCH and CANCEL requests and responses to the 1399 FETCH requests. Section IDs are not to be shown to WATCHERS. 1401 Section-ID = "Section-ID" ":" token 1403 6.12. Section-Name 1405 The Section-Name header field specifies the section name of the 1406 presence section. Section names are used by WATCHERS to specify the 1407 presence sections. When a presence section is to be created, the 1408 CREATESECTION request MUST include this header and the value. 1410 Section-Name = "Section-Name" ":" token 1412 6.13. Location 1414 The Location header field specifies the PePP resource to be 1415 redirected. The REDIRECT request and the NOTIFY request caused by it 1416 MUST include the Location header. 1418 Location = "Location" ":" PePP-Address 1420 6.14. Content-Type 1422 The Content-Type header field indicates the media type of the message 1423 body sent to the recipient. The syntax of the media type is defined 1424 the same as in HTTP/1.1[HTTP1.1]. 1426 As stated in section 3.6., if the media type has 'charset' attribute, 1427 specifying encoding method in 'charset' attribute is STRONGLY 1428 RECOMMENDED. 1430 Content-Type = "Content-Type" ":" type "/" subtype *(";" parameter) 1432 6.15. Content-Length 1434 The Content-Length header field indicates the size of the message 1435 body, in decimal number of octets. The syntax is defined the same as 1436 in HTTP/1.1 [HTTP1.1]. 1438 Content-Length = "Content-Length" ":" 1*DIGIT 1440 6.16. Auth-State 1442 The Auth-State header specifies the status of authentication process 1443 in the LOGIN request. 1445 Auth-State = "Auth-State" ":" ("init" | "continue" | "abort") 1447 6.17. SASL-Mechanism 1449 The SASL-Mechanism header specifies the SASL mechanism in the LOGIN 1450 request or the response to the LOGIN request. When used in the 1451 request, one SASL mechanism the client wants to use MUST be 1452 specified. When used in the response, one or more mechanisms which 1453 the server supports MAY be specified. 1455 SASL-Mechanism = "SASL-Mechanism" ":" mechanism *(LWS mechanism) 1457 6.18. Message-ID 1459 The Message-ID header specifies the identifier of each IM, which 1460 distinguishes the message from others. The client MUST generate the 1461 Message ID unique to the PePP address for each IM. This header MUST 1462 appear in a SEND request. 1464 Message-ID = "Message-ID" ":" token 1466 6.19. Conversation-ID 1468 The Conversation-ID header is used in the SEND request to identify 1469 the conversation channel shared by the participants of IM exchange. 1470 Here, a 'conversation channel' means a virtual channel which consists 1471 of a thread of the IM conversation. When a client replies to an IM 1472 in its same conversation channel, the SEND request for the reply MUST 1473 have the Conversation-ID header with the same value. 1475 Conversation-ID = "Conversation-ID" ":" token 1477 7. PePP Methods 1479 This section describes the methods used in the PePP messages. We use 1480 the following notation to specify the allowable modes of connections 1481 and the directions of requests for each method. 1483 s->s : Server Connections. 1484 c->s : Client Connections, Client-to-Server direction. 1485 s->c : Client Connections, Server-to-Client direction. 1486 c->c : Direct Connections. 1488 7.1. LOGIN 1490 7.1.1. Command 1492 "LOGIN" 1494 7.1.2. Direction 1496 s->s 1497 c->s 1498 c->c 1500 7.1.3. Headers 1502 From 1503 Auth-State 1504 SASL-Mechanism 1505 Connection-Mode 1506 Max-Content-Length 1508 7.1.4. Description 1510 In order to establish the PePP connection, the initiator client or 1511 server MUST issue a LOGIN request to the other peer server to start 1512 authentication process. The Connection-Mode header indicates the 1513 mode of the required connection. When a client logins its Home 1514 Server, it MUST LOGIN the server in the "client" mode. When a server 1515 tries to open a connection with servers in the different domains, it 1516 MUST LOGIN the target server in the "server" mode. 1518 If the authentication process is successfully fulfilled, a PePP 1519 connection is established between the initiator and the target. 1520 Otherwise, the initiator MUST not send any commands. If it try to 1521 send other command in that case, the target server MUST return 401 1522 Unauthorized error. 1524 The authentication process is not necessarily completed in a single 1525 request/response pair, but it can be fulfilled in a sequence of the 1526 request/response pairs. The Auth-State header MUST be used to 1527 indicate the state of the authentication process. The "init" Auth- 1528 State value indicates the initial request in the process, the 1529 "continue" value indicates it is subsequent requests. The SASL- 1530 Mechanism header is used to exchange the SASL mechanism supported by 1531 the initiator and the target server. 1533 Once a PePP connection is established, the initiator MUST NOT send 1534 another LOGIN request to the same connection. The initiator MUST NOT 1535 issue another LOGIN request with "init" Auth-State value in the midst 1536 of the authentication process. In either case, 406 Authentication 1537 Failed response is returned by the server. 1539 The LOGIN request MAY be preceded by the STARTTLS request when the 1540 implementations support TLS for a secure PePP connection. 1542 7.2. LOGOUT 1544 7.2.1. Command 1546 "LOGOUT" 1548 7.2.2. Direction 1550 s->s 1551 c->s 1552 s->c 1553 c->c 1555 7.2.3. Headers 1557 7.2.4. Description 1559 In order to terminate the currently established PePP connection, the 1560 either side of the connection SHOULD issue a LOGOUT request in a 1561 normal situation. The issuer of the LOGOUT request SHOULD wait its 1562 response to confirm the other peer is to send nothing. 1564 7.3. SUBSCRIBE 1566 7.3.1. Command 1568 "SUBSCRIBE" SP PePP-Address 1570 7.3.2. Direction 1572 s->s 1573 c->s 1575 7.3.3. Headers 1577 From 1578 [Subscription-Mode] 1579 [Subscription-ID] 1580 [Regarding] 1581 [Duration] 1583 7.3.4. Discription 1585 The SUBSCRIBE method is used to declare a subscriber's interest at a 1586 PePP resource. The success of SUBSCRIBE request to a resource causes 1587 a change in the Subscribers Information at the resource. 1589 A SUBSCRIBE request MAY include 'Subscription-Mode' header, whose 1590 possible value is "notify", "pull", and "renew". If the "notify" 1591 value is specified, any changes in the subscribed sections will cause 1592 a notification message from the server. If the "pull" value is 1593 specified, the server MUST NOT send notification messages for this 1594 subscription unless the subsequent REQUESTNOTIFY message requests 1595 otherwise. The "renew" value is only specified by the Home Server of 1596 the subscribers in the case of renewing the subscription specified by 1597 the 'Subscription-ID' header field. 1599 There are two kinds of subscriptions regarding the information to be 1600 subscribed; value and control. A SUBSCRIBE request MAY have 1601 'Regarding' header to designate the kind of subscription. Possible 1602 values for this header are 'value' and 'control' respectively. The 1603 default is 'value', which means a usual subscription to the presence 1604 information. 1606 If 'Regarding: control' is specified, the client subscribes to the 1607 Subscribers Information at the resource (see Section 11). 1609 For a SUBSCRIBE request with 'Regarding: value' header field, the 1610 target server determines the permitted presence sections to be shown 1611 based on the ACCESS RULES of the target resource. The response for 1612 the SUBSCRIBE request MUST contain the presence information of the 1613 allowed presence sections unless it is a "renew" request. Even if 1614 the ACCESS RULE changes after the subscription, the currently shown 1615 set of presence sections will not change until the client issues 1616 another SUBSCRIBE request. 1618 The response to a successful SUBSCRIBE request other than "renew" 1619 MUST contain 'Subscription-ID' header specifying the unique 1620 identifier of the subscription, and the 'Duration' header field 1621 specifying the amount of the duration time in seconds. The Home 1622 Server MUST maintain the subscription ID and the duration value in 1623 relation with the subscriber's connection ID, and MUST renew the 1624 subscription on behalf of the subscriber's client. The target server 1625 MUST NOT discard a subscription information before it expires in a 1626 normal situation. The Home Server MUST relay the response containing 1627 the subscription ID, but the client does not have to refer or specify 1628 any duration value. 1630 The maximum number of subscription at a particular resource can be 1631 set. In this case, if the server receives SUBSCRIBE requests 1632 exceeding the maximum, it MAY return a '505 Too Many Subscription' 1633 error. 1635 PePP does not offer any particular method to get the list of presence 1636 sections. So, one who wants a list of presence sections should issue 1637 a SUBSCRIBE request. While PePP does not offer any method to specify 1638 whether or not the pull mode subscription is allowed, an 1639 implementation MAY provide a method to disallow it in an out-of-band 1640 fashion. 1642 7.4. UNSUBSCRIBE 1644 7.4.1. Command 1646 "UNSUBSCRIBE" SP PePP-Address 1648 7.4.2. Direction 1650 s->s 1651 c->s 1653 7.4.3. Headers 1655 From 1656 Subscription-ID 1658 7.4.4. Description 1660 The UNSUBSCRIBE method is used to terminate a previously established 1661 subscription. It MUST include a 'Subscription-ID' identifying the 1662 subscription to be unsubscribed. The absence of this header causes 1663 an error response. This method can be used only by the relevant 1664 subscribers. 1666 7.5. REQUESTNOTIFY 1668 7.5.1. Command 1670 "REQUESTNOTIFY" SP PePP-Address 1672 7.5.2. Direction 1674 s->s 1675 c->s 1677 7.5.3. Headers 1679 From 1680 Subscription-ID 1681 *(Section-Name) 1683 7.5.4. Description 1685 The REQUESTNOTIFY method is used to require change notifications on 1686 the presence sections specified by the Section-Name header fields 1687 through the already established subscription. The subscription is 1688 identified by the specified Subscription-ID, and, if the subscription 1689 does not exist, it will cause a '404 Subscription Not Found' error. 1691 More than one Section-Name header fields MAY be specified at once. 1692 The REQUESTNOTIFY request always overwrite the subscription mode of 1693 each presence section. I.e. the presence sections specified in the 1694 Section-Name headers change to the Notify mode and other sections 1695 change to the Pull mode. If no Section-Name header is specified, all 1696 sections become to be subscribed in the Pull mode. 1698 7.6. CHANGE 1700 7.6.1. Command 1702 "CHANGE" SP PePP-Address 1704 7.6.2. Direction 1706 c->s 1708 7.6.3. Headers 1710 From 1711 Section-ID 1712 Change-Mode 1713 Content-Length 1714 [Duration] 1715 [Content-Type] 1717 7.6.4. Description 1719 The CHANGE method is used to alter the content stored at a given 1720 resource. A CHANGE request MUST be targeted to a single presence 1721 section by specifying the Section-ID header. Section-ID header is 1722 mandatory and its absence causes a '400 Bad Request' error. A 1723 successful CHANGE request may cause notifications to subscribers who 1724 subscribe to the relevant presence section. 1726 A CHANGE request MUST have a Change-Mode header field. The possible 1727 value is one of the four: "lease", "permanent", "renew", and 1728 "revert". A CHANGE request with the Change-Mode "lease" or "renew" 1729 MAY contain the Duration header field which specifies the client's 1730 request of the duration of the lease value. 1732 If "lease" is specified, the content of the message body is set as 1733 the lease value of the presence section. The duration MAY be 1734 specified by the Duration header, but the client MUST use the value 1735 specified by Duration header of the response even if it is different. 1736 The successful CHANGE request resets the lease timer of the section 1737 and causes notification messages to subscribers. If the lease value 1738 is not renewed within the amount of the specified duration value, it 1739 expires and the section reverts to its permanent value. 1741 If "permanent" is specified, the content of the message body is set 1742 as the permanent value of the presence section. If no lease value is 1743 set, it causes to send change notifications to the subscribers. 1745 If "renew" is specified, the lease value of the presence section is 1746 renewed. It resets the lease timer with the duration specified by 1747 the Duration header field in the response. It does not cause any 1748 notifications. 1750 If "revert" is specified, the lease value is removed and the value of 1751 the presence section reverts to its permanent value. It causes 1752 notification messages to subscribers. 1754 7.7. CANCEL 1756 7.7.1. Command 1758 "CANCEL" SP PePP-Address 1760 7.7.2. Direction 1762 c->s 1764 7.7.3. Headers 1766 From 1767 [Section-ID] 1768 [Subscription-ID] 1769 [Cancel-Type] 1771 7.7.4. Description 1773 The CANCEL method is used to direct the target resource to discard 1774 the subscription specified in the Subscription-ID header. This is 1775 only issued by the client of the PRESENTITY. 1777 When a subscription is canceled by a successful CANCEL request, a 1778 NOTIFY request message reporting the cancellation is sent to the 1779 subscriber. If the CANCEL request contains the Cancel-Type header 1780 field (possible values are 'retry' and 'cancel'), the resulting 1781 NOTIFY request MUST contain the Cancel-Type header field with the 1782 same value. If the CANCEL request does not contain the Cancel-Type 1783 header, the resulting NOTIFY request MUST contain the Cancel-Type 1784 header with the value 'cancel'. 1786 Even if the subscription to be canceled is in the Pull mode, such a 1787 reporting NOTIFY message SHOULD be issued. However, in the case that 1788 the NOTIFY message is not delivered to the subscriber successfully, 1789 the subscriber may send a PULL request through the CANCELed 1790 subscription. In this case, the server MUST retrun the '404 1791 Subscription Not Found' error. 1793 If the CANCEL request specifies neither Subscription-ID nor Section- 1794 ID headers, all the subscription SHOULD be canceled at the target 1795 PePP resource. If the CANCEL request has the Section-ID header and 1796 does not include the Subscription-ID header, all the subscriptions in 1797 relation to the specified section SHOULD be canceled. If there the 1798 subscription specified by the Subscription-ID header does not exist, 1799 it MUST cause 404 Subscription Not Found error. 1801 7.8. FETCH 1803 7.8.1. Command 1805 "FETCH" SP PePP-Address 1807 7.8.2. Direction 1809 c->s 1811 7.8.3. Headers 1813 From 1814 Regarding 1815 [Section-ID] 1817 7.8.4. Description 1819 The FETCH method is used to get presence information and/or control 1820 information in the targeted resource. This method is mainly used for 1821 control use by the owner of the resource. 1823 FETCH requests can be targeted both to a resource and to a presence 1824 section contained in a resource. If the FETCH request contains the 1825 Section-ID header, the content of the specified presence section is 1826 returned. The response MUST also include the Section-ID header. 1828 When targeted to an entire resource, and if the resource contains 1829 multiple sections, the contents of multiple sections are returned in 1830 a single response formatted in MIME multipart. Each part MUST 1831 contain the Section-ID header whose value is the Section ID of the 1832 corresponding section. 1834 7.9. NOTIFY 1836 7.9.1. Command 1838 "NOTIFY" SP PePP-Address 1840 7.9.2. Direction 1842 s->s 1843 c->s 1845 7.9.3. Headers 1847 From 1848 Subscription-ID 1849 Section-Name 1850 Content-Length 1851 Content-Type 1852 [Regarding] 1853 [Cancel-Type] 1855 7.9.4. Description 1857 The NOTIFY method is used (1) to report CHANGEs inside a 1858 subscription; and (2) to report CANCELs of subscriptions to the 1859 subscribers. 1861 The NOTIFY request MUST include the Subscription-ID header to specify 1862 the subscription by which the notification is required. This 1863 specification does not specify the behavior of the receiver in the 1864 case the Subscription-ID is missing. 1866 The target address of the NOTIFY request MUST be the address in the 1867 From header of the corresponding SUBSCRIBE request. 1869 The Regarding header has the same value as specified in the 1870 corresponding SUBSCRIBE request. The default value is 'value'. 1872 If a subscription at a resource is canceled by a successful CANCEL 1873 request, it causes the NOTIFY request to the subscriber. Such a 1874 NOTIFY MUST contain the Cancel-Type header field. If the 1875 corresponding CANCEL request contains the Cancel-Type header field 1876 with the value 'retry', the resulting NOTIFY request MUST contain the 1877 Cancel-Type header field with the same value. Otherwise, the NOTIFY 1878 request MUST contain the Cancel-Type header field with the value 1879 'cancel'. 1881 7.10. PULL 1883 7.10.1. Command 1885 "PULL" SP PePP-Address 1887 7.10.2. Direction 1889 s->s 1890 c->s 1892 7.10.3. Headers 1894 From 1895 Subscription-ID 1896 [Section-Name] 1898 7.10.4. Description 1900 The PULL method is used to get the content of the resource which is 1901 currently subscribed by the same issuer of this message. The PULL 1902 request MUST contain 'Subscription-ID' header, and the value of this 1903 header MUST contain a valid subscription ID. 1905 If the PULL request does not have a Section-Name header, the response 1906 contains all the disclosed sections encoded in MIME Multipart. 1908 7.11. SEND 1910 7.11.1. Command 1912 "SEND" SP PePP-Address 1914 7.11.2. Direction 1916 s->s 1917 c->s 1918 s->c 1919 c->c 1921 7.11.3. Headers 1923 From 1924 Message-ID 1925 Content-Length 1926 Content-Type 1927 [Conversation-ID] 1929 [Reply-To] 1931 7.11.4. Description 1933 The SEND method is used to send arbitrary content to a targeted PePP 1934 address. This is usually used for IMs. 1936 The SEND request MUST contain the Message-ID header whose value is 1937 the globally unique identifier of the message. The client MUST have 1938 responsibility for the uniqueness. 1940 If the receivers are set by the RECEIVE requests at the target 1941 resource of the SEND request, the server MUST issue another SEND 1942 request with the same PePP Resource and header fields to the receiver 1943 connections. If the target resource has no receivers, the '502 1944 Service Unavailable' error is returned. 1946 When the client wishes to start a conversational IM exchange, the 1947 SEND request MUST contain the Conversation-ID header field whose 1948 value is a globally unique identifier to be shared by the 1949 participants of the conversation. Assume that a client has reveived 1950 an IM with the Conversation-ID header. If the client wishes to reply 1951 to it in the same conversation channel, it MUST specify the same 1952 Conversation-ID field in the reply SEND message. 1954 The SEND request is REQUIRED to tranport any MIME entity. Thus, it 1955 MAY contain any legal MIME header which may not be defined here. The 1956 servers MUST forward the SEND message as is when the message is 1957 relayed to the clients or other servers. That is, the servers MUST 1958 NOT delete or modify any header which appears in the SEND message. 1960 7.12. RECEIVE 1962 7.12.1. Command 1964 "RECEIVE" SP PePP-Address 1966 7.12.2. Direction 1968 c->s 1970 7.12.3. Headers 1972 7.12.4. Description 1974 The RECEIVE method is used to specify the connection to forward the 1975 delivered SEND message at the target resource. When the server 1976 receives the RECEIVE request, the Client connection of the issuer 1977 client is set as a 'Receiver' connection at the target resource. 1979 More than one 'Receiver' connections MAY be set if other clients 1980 issue the RECEIVE request at the same resource. The server MUST 1981 manage the 'Receiver' connections of every resources in it, and, when 1982 it receives a SEND message targeted at the resource, it MUST issue 1983 the new SEND requests with the same PePP-Address and headers to its 1984 'Receiver' connections. 1986 7.13. CALLBACK 1988 7.13.1. Command 1990 "CALLBACK" 1992 7.13.2. Direction 1994 s->c 1996 7.13.3. Headers 1998 Max-Content-Length 1999 [Location] 2000 [Connection-Mode] 2002 7.13.4. Description 2004 The CALLBACK method is used by the server to ask the client to create 2005 a new "backup" Client Connection. 2007 The server will use the newly established connection to send the 2008 message whose body size exceeds the Max-Content-Length values of the 2009 existing Client Connections. 2011 The CALLBACK request MUST contain the Max-Content-Length header field 2012 to tell the required value for new connection. 2014 The server MAY specify the Location header field to specify a 2015 different server location and/or port number to be called back from 2016 the client. If Location header value contains other than server and 2017 port number, rest part of PePP-Address will be ignored. 2019 If the client accepts the request, it returns '200 OK' as the 2020 response and it MUST issue a LOGIN request to a newly opened TCP 2021 connection to establish a "backup" Client Connection. If the client 2022 rejects the request, the client returns '402 Permission Denied' 2023 response. 2025 The Target Server will use this request to ask the Target Client for 2026 creating "raw TCP connection", which provides the Direct Connection. 2027 In this case, the CALLBACK command MUST contain the Connection-Mode 2028 header field with the value "direct". 2030 7.14. REDIRECT 2032 7.14.1. Command 2034 "REDIRECT" SP PePP-Address 2036 7.14.2. Direction 2038 c->s 2040 7.14.3. Headers 2042 Location 2044 7.14.4. Description 2046 The REDIRECT method is used to specify the address for redirection of 2047 the SUBSCRIBE or SEND request to the PePP resource. A successful 2048 REDIRECT request results in returning the 300 Moved Temporary 2049 response to the subsequent SUBSCRIBE or SEND requests. Established 2050 subscriptions at the time of the REDIRECT request are still alive as 2051 they were. PULL requests through the subscriptions MAY still be 2052 accepted. As the subscribers cannot know the target resource was 2053 REDIRECTed, the client MUST issue CANCEL request in order to tell the 2054 subscribers that the resource was REDIRECTed. 2056 The destination resource of the redirection is specified in the 2057 Location header. The REDIRECT request without a Location header 2058 cancels the redirection settled before. Even if no redirection was 2059 settled, cancellation request is returned with 200 OK. 2061 7.15. SETACL 2063 7.15.1. Command 2064 "SETACL" SP PePP-Address 2066 7.15.2. Direction 2068 c->s 2070 7.15.3. Headers 2072 Content-Type 2073 Content-Length 2075 7.15.4. Description 2077 The SETACL method is used to specify the ACL at the targeted 2078 resource. The message body of the SETACL request is used as a new 2079 ACL. The format of the ACL is described in Section 12. 2081 The owner of the resource, or a user specially authorized by the 2082 system administrator, can issue the SETACL requests. 2084 7.16. GETACL 2086 7.16.1. Command 2088 "GETACL" SP PePP-Address 2090 7.16.2. Direction 2092 c->s 2094 7.16.3. Headers 2096 7.16.4. Description 2098 The GETACL method is used to acquire the ACL at the targeted 2099 resource. The successful response contains the currently set ACL at 2100 the resource in its body part. The format of the ACL is described in 2101 Section 12. 2103 The owner of the resource, or a user specially authorized by the 2104 system administrator, can issue the GETACL requests. 2106 7.17. CREATESECTION 2108 7.17.1. Command 2109 "CREATESECTION" SP PePP-Address 2111 7.17.2. Direction 2113 c->s 2115 7.17.3. Headers 2117 Section-ID 2118 Section-Name 2119 Content-Type 2120 Content-Length 2122 7.17.4. Description 2124 The CREATESECTION request is used to create a new presence section. 2125 Section-ID and Section-Name are mandatory headers and, if either of 2126 those is omitted, it causes 400 Bad Request error. The message body 2127 is set as a permanent value of this section. 2129 The server checks the uniqueness of the Section-ID at the resource, 2130 and return 405 Section Already Exists if there already exists. This 2131 request does not contain any content of the presence section. 2133 7.18. DELETESECTION 2135 7.18.1. Command 2137 "DELETESECTION" SP PePP-Address 2139 7.18.2. Direction 2141 c->s 2143 7.18.3. Headers 2145 Section-ID 2147 7.18.4. Description 2149 The DELETESECTION request is used to delete the specified presence 2150 section. The Section-ID header is mandatory. If absence, 400 Bad 2151 Request error is returned. If the section is still subscribed, a 2152 '407 Subscription Still Exists' error is returned. 2154 7.19. PING 2155 7.19.1. Command 2157 "PING" 2159 7.19.2. Direction 2161 s->s 2162 c->s 2163 s->c 2164 c->c 2166 7.19.3. Headers 2168 7.19.4. Description 2170 The PING request is used by the server or the client to confirm that 2171 the PePP connection is alive. When this request is received, the 2172 receiver MUST return '200 OK' response. 2174 7.20. STARTTLS 2176 7.20.1. Command 2178 "STARTTLS" 2180 7.20.2. Direction 2182 s->s 2183 c->s 2185 7.20.3. Headers 2187 7.20.4. Description 2189 A client or server MAY issue STARTTLS request to upgrade the existing 2190 TCP connection to the TLS [TLS] (formerly known as SSL) enabled one 2191 instead of using separate port for "secure" PePP connection. 2192 Implementations that support TLS SHOULD issue a STARTTLS request 2193 prior to issuing any other requests. 2195 A TLS negotiation begins immediately after the "200 OK" response from 2196 the another peer. Once a STARTTLS command issued, the initiator MUST 2197 NOT issue further requests until a server response is received and 2198 the TLS negotiation is completed. 2200 Once the client credentials are successfully exchanged using TLS 2201 negotiation, the "EXTERNAL" SASL mechanism MAY be used in the 2202 subsequent LOGIN process. The "PLAIN" SASL mechanism MUST NOT be 2203 used if the STARTTLS upgrading process fails to establish a fully 2204 strong encryption layer. 2206 The implementation which does not support TLS SHOULD return the "501 2207 Not Implemented" response. In this case, the client MUST 2208 authenticate itself in the following LOGIN process. 2210 7.21. CONNECT 2212 7.21.1. Command 2214 "CONNECT" SP PePP-Address 2216 7.21.2. Direction 2218 s->s 2219 c->s 2221 7.21.3. Headers 2223 From 2225 7.21.4. Description 2227 The CONNECT method is used to establish the Direct Connection between 2228 clients. The established connection will provide a private 2229 conversation channel for IMs. 2231 The CONNECT request issued by a client intended to the other client 2232 is sent to the Home Server, and is forwarded to the Target Server by 2233 opening a new connection. Then, the Target Server issues a CALLBACK 2234 request to the destination client to tell the request from the 2235 initiator client (see Section 3.3.3 for details). 2237 8. Status Codes 2239 The policy for assigning PePP status codes basically follows the 2240 convention used in HTTP/1.1 [HTTP1.1]. 2242 - 1xx: Informational - Request received, continuing process 2244 - 2xx: Success - The action was successfully received, 2245 understood, and accepted 2247 - 3xx: Redirection - Further action must be taken in order to 2248 complete the request 2250 - 4xx: Client Error - The request contains bad syntax or cannot 2251 be fulfilled 2253 - 5xx: Server Error - The server failed to fulfill an apparently 2254 valid request 2256 8.1. 1xx 2258 8.1.1. 100 Authentication Continued 2260 The request for authentication has been accepted and the 2261 authentication process is continued. 2263 8.2. 2xx 2265 8.2.1. 200 OK 2267 8.2.2. 201 Subscription Created 2269 It appears in the response to a SUBSCRIBE request, reporting the 2270 successful result. In the subscription for 'Regarding: value' and 2271 'control', the relevant content MUST be contained in the response. 2273 8.2.3. 202 Section Created 2275 It appears in the response to a CREATESECTION request, reporting the 2276 successful result. 2278 8.3. 3xx 2280 8.3.1. 300 Moved Temporary 2282 The requested resource has been assigned a new URI temporarily and 2283 the requester SHOULD resend the request to the specified resource. 2284 The new URI MUST be given by the Location header field in the 2285 response. It depends on the server's policy to select the 300 or 301 2286 response. 2288 8.3.2. 301 Moved Permanently 2290 The requested resource has been assigned a new permanent URI and any 2291 future references to this resource SHOULD use the returned URI. The 2292 new permanent URI MUST be given by the Location header field in the 2293 response. It depends on the server's policy to select the 300 or 301 2294 response. 2296 8.4. 4xx 2298 8.4.1. 400 Bad Request 2300 The request could not be understood by the server due to malformed 2301 syntax. The client SHOULD NOT repeat the request without 2302 modifications. 2304 8.4.2. 401 Unauthorized 2306 The request requires user authentication. The client MUST 2307 authenticate itself by the LOGIN request. 2309 8.4.3. 402 Forbidden 2311 The server understood the request, but it has not been authorized. 2313 8.4.4. 403 Resource Not Found 2315 The specified resource was not found at the server. 2317 8.4.5. 404 Subscription Not Found 2319 The Subscription specified in the Subscription-ID header was not 2320 found at the resource. This status code MAY appear in the response 2321 to the UNSUBSCRIBE, CANCEL, PULL requests and the SUBSCRIBE request 2322 in "renew" mode. 2324 8.4.6. 405 Section Already Exists 2326 The section specified in the Section-ID header of the CREATESECTION 2327 request already exists. 2329 8.4.7. 406 Authentication Failed 2331 The authentication process has been failed. The reason for it is one 2332 of the followings. 2334 o The authentication process using the specified SASL-Mechanism 2335 was failed. 2336 o The LOGIN request does not specify any SASL-Mechanism. 2337 o The LOGIN request specifies inappropriate SASL-Mechanism. 2338 o In the midst of the authentication process, the client tries to 2339 start another authentication process by specifying 2340 'Auth-State: init'. 2342 This response MAY contain a SASL-Mechanism header specifying the 2343 applicable SASL-Mechanism. 2345 8.4.8. 407 Subscription Still Exists 2347 The request has not been fulfilled because the subscription to the 2348 specified section still exists. This status code appears in the 2349 response to the DELETESECTION request. The client which has received 2350 this response MUST send a CANCEL request before requesting the 2351 DELETESECTION. 2353 8.5. 5xx 2355 8.5.1. 500 Internal Server Error 2357 The request has not been fulfilled because of the error internal to 2358 the server. 2360 8.5.2. 501 Not Implemented 2362 The server does not support the functionality required to fulfill the 2363 request. 2365 8.5.3. 502 Service Unavailable 2367 This status code is returned when the client issues the SEND request 2368 to the resource which any 'receiver' connection is not set. 2370 8.5.4. 503 PePP Version Not Supported 2372 The server or the client does not support the specified version of 2373 PePP used for the request. 2375 8.5.5. 504 Gateway Timeout 2377 The server forwarded the request to the specified server, but has not 2378 been received within the time that it was prepared to wait. the 2379 forwarded request has been timeout. 2381 8.5.6. 505 Too Many Subscription 2383 The SUBSCRIBE request has not been fulfilled because the request 2384 exceeds the specified maximum number of subscription at the resource. 2385 When received this status code, the client SHOULD NOT retry 2386 subscription immediately. 2388 9. Presence Information Data Format 2390 9.1. Overview 2392 In PePP, Presence Information is encoded in Well-Formed XML without a 2393 DTD. Although any XML components MAY appear as a presence data, only 2394 the elements defined in this documents have a meaning. 2396 Presence Information at a PePP resource is composed of a set of 2397 presence sections, each of which is contained in the
2398 element. Each presence section has a unique identifier called Section 2399 ID, which is not to be shown to subscribers, and a section name which 2400 is sent to subscribers for the sake of selective subscription. 2401 However, both of section IDs and names are not included in the 2402 content of Presence Information. Instead, for each presence section, 2403 a display-name is contained in the content of PI to be displayed to 2404 subscribers. Display names are contained in the content of 2405 element. 2407 A typical example of Presence Information is availability of 2408 communication means, such as IM and telephone. Such information is 2409 contained in a sub-element. The 2410 element contains
, and and sub- 2411 elements. 2413 For IM, the
element contains the PePP address of the 2414 recipient. For the communication means where the target address can 2415 be expressed by a URL, the
element contains the URL (ex. 2416
tel:+81-123-456-7890
). For other communication 2417 means, the element contains supplementary information for the 2418 communication means. 2420 Example: 2422
2423 2424
pepp://pepp.org/Alice/iibox
2425 2426 2427 Out to Lunch. 2428 IM 2429
2431 Example: 2433
2434 2435
tel:+81-123-456-7890
2436 2437 2438 Telephone at Home 2439
2441 The element MAY have a sub-element, 2442 which specifies the device capability of the communication means or 2443 the user's preference. Although this document does not specifies the 2444 concrete format of capability, we will allow to contain a URL where a 2445 capability for the device is stored in other future standard format 2446 as CONNEG or CC/PP [CC/PP]. 2448 9.2. Tag Descriptions 2450 9.2.1. section 2452 Tag: section 2453 Context: top level 2454 Appearance: mandatory 2455 Sub-elements: display-name note ( communication | principal ) 2456 Description: 2457 The section tag is top-level tag for presence sections. 2459 9.2.2. display-name 2461 Tag: display-name 2462 Appearance: mandatory 2463 Context: section 2464 Sub-elements: none 2465 Description: 2466 Text to be displayed by the client UI. 2468 9.2.3. note 2470 Tag: note 2471 Appearance: optional 2472 Context: section 2473 Sub-elements: none 2474 Description: 2475 Text to be handled as a short note in relation to the presence 2476 information. 2478 9.2.4. communication 2480 Tag: communication 2481 Appearance: mandatory 2482 Context: section 2483 Sub-elements: address communication-status capability 2484 Description: 2485 Information about communication means is contained. This element 2486 appears in a section element if the section is used to express 2487 status of a communication means. This element can have additional 2488 sub-elements. 2490 9.2.5. communication-status 2492 Tag: status 2493 Appearance: mandatory 2494 Context: section 2495 Sub-elements: ( open | closed ) 2496 Description: 2497 Availability of the communication means. 2499 9.2.6. open 2501 Tag: open 2502 Appearance: mandatory 2503 Context: status 2504 Sub-elements: ( busy | away ) 2505 Description: 2506 The open tag means that the communication device is available. 2507 It MAY contain other elements not defined here. 2509 9.2.7. closed 2511 Tag: closed 2512 Appearance: mandatory 2513 Context: status 2514 Sub-elements: none 2515 Description: 2516 The closed tag means that the communication device is not 2517 available. 2519 9.2.8. busy 2521 Tag: busy 2522 Appearance: optional 2523 Context: open 2524 Sub-elements: none 2525 Description: 2526 The communication device is available, but a communication 2527 request may not be noticed because the user is busy. 2529 9.2.9. away 2530 Tag: away 2531 Appearance: optional 2532 Context: open 2533 Sub-elements: none 2534 Description: 2535 The communication device is available, but a communication 2536 request may not be noticed because the user is away from the 2537 device. 2539 9.2.10. capability 2541 Tag: capability 2542 Appearance: optional 2543 Context: section 2544 Sub-elements: none 2545 Description: 2546 If this element appears, the capability information of the 2547 corresponding communication device can be retrieved. 2549 9.2.11. address 2551 Tag: address 2552 Appearance: mandatory 2553 Context: communication 2554 Sub-elements: none 2555 Description: 2556 The address of the communication device in the form of URI. 2558 9.2.12. principal 2560 Tag: principal 2561 Appearance: mandatory 2562 Context: section 2563 Sub-elements: principal-status 2564 Description: 2565 Information in relation to the relevant principal is contained. 2566 The principal usually has various status information other than 2567 any communication means. This tag is for such information. 2569 9.2.13. principal-status 2571 Tag: status 2572 Appearance: mandatory 2573 Context: principal 2574 Sub-elements: none 2575 Description: 2576 Status information for the principal which may be used by 2577 the applications. 2579 10. Subscribers Information 2581 The owner or specially authorized user can get the information of the 2582 current subscribers at the resource. This is called Subscribers 2583 Information. The Subscribers Information is a list of subscription 2584 information at the resource, each of which contains the subscription 2585 ID, the subscriber's PePP address, the date of the subscription, and 2586 so on. 2588 The Subscribers Information can be acquired by a SUBSCRIBE or FETCH 2589 request in 'Regarding: control'. Even if the Section-Name header 2590 appears in this request, it MUST be ignored. If the 'Subscription- 2591 Type: Notify' is specified, any change at the Subscribers Information 2592 will be notified. 2594 The syntax of Subscribers Information is based on XML, and is defined 2595 by the following ABNF. 2597 information = "" 1*subscription "" 2598 subscription = "" subscription-ID subscriber 2599 created mode regarding "" 2600 subscription-ID = "" token "" 2601 subscriber = "" PePP-Address "" 2602 created = "" date "T" time "Z" "" 2603 mode = "" ("notify" / "pull") "" 2604 regarding = "" ("value" / "control") "" 2606 Here, the "created" element represents the date that the subscription 2607 was created. The format of the value is same as the Last-Modified 2608 header field specified in section 6.10. 2610 The "mode" element represents the Subscription-Mode of the 2611 subscription which is defined in section 6.4 and 7.3. 2613 The "regarding" element represents what property of the resource is 2614 subscribed. The value and its semantics is same as the Regarding 2615 header field in corresponding SUBSCRIBE request. 2617 Example: 2619 2620 2621 a1b2c3d4e5f6 2622 pepp://pepp.org/bob 2623 2000-06-10T09:10:43Z 2624 notify 2625 value 2626 2627 .... 2628 2630 11. Access Control List 2632 11.1. Overview 2634 Access Control in PePP has two aspects; one is to decide allowing or 2635 rejecting the access request from the requesters, and the other is to 2636 select which presence sections should be disclosed to the 2637 SUBSCRIBERS. The user controlling a PePP resource can indicate how 2638 to handle the requests to it specifying Access Control List (ACL). 2640 The PePP ACL specifies the action of the server at the time of 2641 receiving the following requests; SUBSCRIBE, SEND, FETCH, CHANGE, 2642 CANCEL, REDIRECT. For all of those requests but SUBSCRIBE, an 2643 allow-list and deny-list can be specified in the ACL. For SUBSCRIBE 2644 requests, a disclose-list can be specified for each section instead 2645 of an allow-list. This is a design decision based on our experience 2646 through the practice of presence services in our company. 2648 By default, all requests are handled as they are denied, or nothing 2649 is disclosed, unless the system configuration allows. Because 2650 presence and instant messaging services are pretty sensitive to 2651 privacy issues, we took a safer side. 2653 11.2. ACL Functions 2655 11.2.1. SUBSCRIBE 2657 For the SUBSCRIBE request, a basic action is 'deny' and 'disclose'. 2658 The ACL has a deny list and a disclose list for SUBSCRIBE. 2660 o Deny-list is a list of principals whose requests are denied. 2661 o Disclose-list is a set of lists, each of which is a list of 2662 principals allowed for each section. 2664 A deny-list and a disclose-list appears once in the ACL, and the 2665 deny-list has a priority over the disclose list. In other words, a 2666 request from a principal matching the deny-list is rejected 2667 regardless of the disclose-list. The default action is also 'deny'. 2669 Each section is specified by the Section ID and Section names does 2670 not appear in the ACL. This implies that it is possible to show more 2671 than one sections with the same name. The current specification does 2672 not forbid this situation. 2674 A 'default' tag MAY be assigned to one or more sections. The 2675 assigned section becomes a default section, which is shown when no 2676 section to be shown was specified explicitly. 2678 11.2.2. SEND, FETCH, CHANGE, CANCEL, REDIRECT 2680 For the SEND, FETCH, CHANGE, CANCEL, and REDIRECT requests, a basic 2681 action is 'deny' and 'allow', same as the conventional ACLs. The ACL 2682 has a deny list and an allow list for them. 2684 o Deny-list is a list of principals whose requests are denied. 2685 o Allow-list is a list of principals whose requests are allowed. 2687 A deny-list and an allow-list appears once in the ACL, and the deny- 2688 list has a priority over the allow-list unless otherwise stated. In 2689 other words, a request from a principal matching the deny-list is 2690 rejected regardless of the allow-list. The default action is also 2691 'deny'. 2693 The priority can be reversed by specifying the 'priority-allow' tag. 2694 In this case, the allow-list has a priority over the deny-list and 2695 the default action becomes 'allow'. 2697 11.3. Syntax of ACL 2699 The syntax of ACL in PePP is based on XML as defined in this section. 2700 Command Names and Section IDs are case-sensitive. 2702 The syntax is defined by the following ABNF. 2704 acl = "" subscribe *other-command "" 2705 subscribe = "" [deny-list] disclose-list "" 2706 disclose-list = "" 1*section "" 2707 section = "
" section-body "
" 2708 section-body = section-id (default / all / user-group-list) 2709 user-group-list = *(user / group) 2710 default = "" 2711 other-command = "" command-body "" 2712 command-body = command-name [reverse-priority] [allow-list] [deny- 2713 list] 2714 command-name = "" command-token "" 2715 command-token = "SEND" / "FETCH" / "CHANGE" / "CANCEL" / "REDIRECT" 2716 reverse-priority = "" 2717 allow-list = "" (all / user-group-list) "" 2718 deny-list = "" user-group-list "" 2719 user = "" user-id "" 2720 group = "" group-name "" 2721 all = "" 2723 Here, tag is prepared for the future extension where a group 2724 of users can be specified as a principal. 2726 Example: 2728 2729 2730 2731 pepp://pepp.fujitsu.com/suga 2732 2733 2734
2735 for-office1 2736 pepp://pepp.fujitsu.com/sho 2737 group2 2738
2739
2740 for-office2 2741 group1 2742 group2 2743
2744
2745 private 2746 pepp://pepp.fujitsu.com/iwakawa 2747 pepp://pepp.fujitsu.com/sho 2748
2749
2750 default 2751 2752
2753 2754 2756 2757 FETCH 2758 2759 group1 2760 group2 2761 2762 2763 2764 SEND 2765 2766 2767 2768 2769 pepp://foo.net/unknown 2770 2771 2772 2774 12. Sample Transcripts 2776 Consider Alice starts to connect to her home server and her PePP 2777 address is "pepp://pepp.fujitsu.com/alice". 2779 12.1. LOGIN 2781 // In order to login the PePP service, the client initiate the LOGIN 2782 // request to establish a PePP connection. 2783 // Alice connects PePP service, 2784 // opening the PePP connection from her client to port ??? of 2785 // pepp.fujitsu.com 2787 LOGIN 00153678 PePP/0.5 2788 From: pepp://pepp.fujitsu.com/alice 2789 SASL-mechanism: CRAM-MD5 2790 Auth-State: init 2792 // Response from server. 2793 // A challenge is given as the content 2795 PePP/0.5 00153678 100 Authentication Continued 2796 Content-Type: text/plain 2797 Content-Length: xxx 2799 1234.14782225@pepp.org 2801 // The client returns a response in the succeeding LOGIN request 2803 LOGIN 00153679 PePP/0.5 2804 From: pepp://pepp.fujitsu.com/alice 2805 Auth-State: continue 2806 Content-Type: text/plain 2807 Content-Length: xxx 2808 alice b913a602c7eda7a495b4e6e7334d3890 2810 // Authentication succeeded 2812 PePP/0.5 00153679 200 OK 2814 12.2. CREATESECTION 2816 // Alice creates a new section containing an IM presence. 2817 // This content is set as a permanent value of this section. 2819 CREATESECTION pepp://pepp.fujitsu.com/alice 00153783 PePP/0.5 2820 From: pepp://pepp.fujitsu.com/alice 2821 Section-ID: PublicIM 2822 Section-Name: IM 2823 Content-Type: text/xml 2824 Content-Length: yyy 2826
2827 Instant Message 2828 2829 2830
pepp://pepp.fujitsu.com/alice/iibox
2831 2832
2834 // The new section was successfully created. 2836 PePP/0.5 00153783 202 Section Created 2838 12.3. CHANGE 2840 // Alice changes her presence information 2842 CHANGE pepp://pepp.fujitsu.com/alice 00153793 PePP/0.5 2843 From: pepp://pepp.fujitsu.com/alice 2844 Section-ID: PublicIM 2845 Duration: 180 2846 Content-Type: text/xml 2847 Content-Length: xxx 2849
2850 Instant Message 2851 Meeting, Room 5B 2852 2853 2854
pepp://pepp.org/alice/iibox
2855 2856
2858 // Presence information was successfully changed 2860 PePP/0.5 00153793 200 OK 2861 Duration: 180 2863 12.4. SUBSCRIBE 2865 // Bob subscribes to Alice's presence information. 2866 // Assumes that ACL specifies to show "PublicIM" (Section-ID) for 2867 // the subscription from Bob. The section has a Section-Name "IM". 2868 // The disclosed content of the presence information is returned 2869 // as an initial value. 2871 SUBSCRIBE pepp://pepp.fujitsu.com/alice 02658472 PePP/0.5 2872 From: pepp://pepp.org/bob 2873 Subscription-Mode: Notify 2874 Regarding: value 2876 // Subscription has succeeded, and Bob's client receives the 2877 // response with Alice's PI at the moment. 2879 PePP/0.5 02658472 201 Subscription Created 2880 Subscription-ID: a1b2c3d4e5f6 2881 Content-Type: multipart/mixed; boundary="Multipart0123456789" 2882 Content-Length: xxx 2884 --Multipart0123456789 2885 Content-Type: text/xml 2886 Content-Length: zzz 2887 Last-Modified: 2000-06-10T09:10:43Z 2889
2890 Instant Message 2891 Meeting, Room 5B 2892 2893 s 2894
pepp://pepp.org/alice/iibox
2895 2896
2897 --Multipart0123456789 2898 ( if other section is allowed for Bob to subscribe, they will appear here.) 2899 --Multipart0123456789 2901 12.5. NOTIFY 2903 // When Alice changes her presence, it is notified to the subscriber. 2905 NOTIFY pepp://pepp.org/bob 31975431 PePP/0.5 2906 From: pepp://pepp.fujitsu.com/alice 2907 Section-Name: IM 2908 Subscription-ID: a1b2c3d4e5f6 2909 Last-Modified: 2000-06-10T12:03:22Z 2910 Content-Type: text/xml 2911 Content-Length: xxx 2913
2914 Instant Message 2915 I'm back! 2916 2917 2918
pepp://pepp.org/alice/iibox
2919 2920
2922 // The client returns a successful response. 2924 PePP/0.5 31975431 200 OK 2926 12.6. SEND 2928 // Bob sends IM to Alice. 2930 SEND pepp://pepp.fujitsu.com/alice/iibox 01348590 PePP/0.5 2931 From: pepp://pepp.org/bob 2932 Message-ID: 200006101523.ZDFN0478//pepp.org/bob 2933 Conversation-ID: 200006101523.ZDFN0478//pepp.org/bob 2934 Content-Type:text/plain 2935 Context-Length: xxx 2937 Hello! 2939 // The server returns a successful response if the message is 2940 // deliverable. 2942 PePP/0.5 01348590 200 OK 2944 // Then the server fowards the message to the client connection. 2946 SEND pepp://pepp.fujitsu.com/alice/iibox 31978216 PePP/0.5 2947 From: pepp://pepp.org/bob 2948 Message-ID: 200006101523.ZDFN0478//pepp.org/bob 2949 Conversation-ID: 200006101523.ZDFN0478//pepp.org/bob 2950 Content-Type:text/plain 2951 Context-Length: xxx 2953 Hello! 2955 // The Alice's client returns a successful response. 2957 PePP/0.5 31978216 200 OK 2959 12.7. LOGOUT 2961 // Alice closes the PePP connection. 2963 LOGOUT 00258674 PePP/0.5 2964 From: pepp://pepp.fujitsu.com/alice 2966 // The server returns a successful response. 2968 PePP/0.5 00258674 200 OK 2970 // Alice's client closes the TCP connection. 2972 13. Security Considerations 2974 Security considerations are described in Section 4.2. 2976 14. Acknowledgments 2978 Some of the ideas in this document are inspired by private 2979 correspondence with John Stracke, eCal Corp., especially for IM 2980 transfer and IM conversation. The authors gratefully acknowledge his 2981 contributions. 2983 15. References 2985 [Model] M.Day, J.Rosenberg, H.Sugano, "A Model for Presence and Instant 2986 Messaging", RFC 2778, February 2000. 2987 [Reqts] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant Messaging 2988 / Presence Protocol Requirements", RFC 2779, February 2000. 2989 [RelURL] R.Fielding, "Relative Uniform Resource Locators", RFC1808 2990 [HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 2991 P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2992 RFC 2616, June 1999 2993 [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", 2994 RFC2222, October 1997. 2995 [SASL-PLAIN] C. Newman, "Using TLS with IMAP, POP3 and ACAP", RFC2595, 2996 June 1999. 2997 [CRAM-MD5] J.Klensin, R.Catoe and P. Krumviede, "IMAP/POP AUTHorize 2998 Extension for Simple Challenge/Response", RFC 2195, September 1997. 2999 [TLS] T.Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC2246, 3000 January 1999. 3001 [MIME] N. Freed et al., "Multipurpose Internet Mail Extensions (MIME) 3002 Part One" to "Five", RFC 2045-2049, November 1996. 3003 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 3004 Identifiers (URI): Generic Syntax", RFC2396, August 1998. 3005 [ISO8601] "Data elements and interchange formats -- Information 3006 interchange -- Representation of dates and times", 1988. 3007 [CC/PP] M.Nilsson, J.Hjelm, H.Ohto, "Composit Capabilities/Preference 3008 Profiles: Requirements and Architecture", W3C CC/PP Working Group, 3009 http://www.w3.org/TR/CCPP-ra/, February, 2000. 3011 16. Authors' Addresses 3013 Hiroyasu Sugano 3014 Fujitsu Laboratories Ltd. 3015 64 Nishiwaki, Ohkubo-cho 3016 Akashi 674-8555 3017 Japan 3018 email: suga@flab.fujitsu.co.jp 3020 Akinori Iwakawa 3021 Fujitsu Laboratories Ltd. 3022 64 Nishiwaki, Ohkubo-cho 3023 Akashi 674-8555 3024 Japan 3025 email: iwakawa@flab.fujitsu.co.jp 3027 Koji Otani 3028 Fujitsu Laboratories Ltd. 3029 64 Nishiwaki, Ohkubo-cho 3030 Akashi 674-8555 3031 Japan 3032 email: sho@flab.fujitsu.co.jp 3033 Takashi Ohno 3034 Fujitsu Laboratories Ltd. 3035 64 Nishiwaki, Ohkubo-cho 3036 Akashi 674-8555 3037 Japan 3038 email: ohno@flab.fujitsu.co.jp 3040 Shingo Fujimoto 3041 Fujitsu Laboratories of America, Inc. 3042 595 Lawrence Expressway 3043 Sunnyvale, CA 94086 3044 USA 3045 email: shingo@fla.fujitsu.com