idnits 2.17.1 draft-mohr-pip-pipdemo-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1030 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 749 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 195: '...style pipelining MAY be implemented; s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (7 August 1998) is 9391 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT G. Mohr, Activerse 2 Expires: February 7, 1999 S. Aggarwal, Microsoft 3 M. Day, Lotus 4 A. Houri, Ubique 5 Y. Kohda, Fujitsu 6 D. Marvit, Fujitsu 8 7 August 1998 10 PIP-DEMO: An Interoperable Presence Information Protocol 11 draft-mohr-pip-pipdemo-00.txt 13 1. Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 30 Coast), or ftp.isi.edu (US West Coast). 32 Distribution of this document is unlimited. Please send comments 33 to the PIP discussion group at pip@iastate.edu. Discussions of 34 the group are archived at http://lists.fsck.com/cgi-bin/wilma/pip. 36 2. Abstract 38 PIP/0.2 is a demonstration protocol designed as a testbed 39 for certain ideas about meeting 'Presence Information Protocol' 40 requirements in a straightforward, interoperable fashion. 41 Drawing from earlier proposals in this area, PIP/0.2 aims to: 43 1) Enable basic 'presence information' sharing 44 2) Enable simple text messaging; and 45 3) Remain easy to understand and implement 47 PIP/0.2 specifically makes NO attempt to be: 49 1) Secure 50 2) Scalable/efficient; or 51 3) Rigorously specified 53 3. Contents 55 1. Status of this Memo 56 2. Abstract 57 3. Contents 58 4. Introduction 59 5. Naming 60 6. Message format 61 7. Transport 62 8. Character Encoding 63 9. Methods 64 9.1 SUBSCRIBE 65 9.2 UNSUBSCRIBE 66 9.3 CHANGE 67 9.4 NOTIFY 68 9.5 FETCH 69 10. Response Codes 70 11. Headers 71 11.1 Adopted from HTTP/1.1 Without Change 72 11.2 Duration 73 11.3 Renew-Duration 74 11.4 From 75 11.5 Origin 76 11.6 Sendback 77 11.7 Subscription-ID 78 11.8 Notify-class 79 11.9 Regarding 80 12. Leases 81 13. Subscriptions 82 14. Redirections 83 15. Domain Conventions 84 15.1 Presence Information 85 15.2 Messaging 86 15.3 Establishing Redirection (Optional) 87 16. Proxying 88 17. Security 89 18. Examples 90 18.1 Establishing availability 91 18.2 Subscribing to others 92 18.3 Instant messaging 93 18.4 Publishing from elsewhere 94 19. References 95 20. Author Addresses 97 4. Introduction 99 At any moment, millions of people worldwide are interacting with 100 the Internet. But can they interact with each other? 102 Often they cannot, because the Internet lacks a standard, widely 103 deployed mechanism for people to advertise dynamic information 104 about their online status, and exchange simple, endpoint-to- 105 endpoint messages. 107 A burgeoning category of applications known as "buddy lists", 108 "people browsers", "pagers", "messengers", or "colleague awareness 109 tools" have sought to provide these capabilities, but so far such 110 applications have used proprietary schemes: undocumented 111 protocols, closed namespaces, and centrally-administered service 112 centers. 114 A number of companies and individuals have begun an effort to 115 adopt an open, interoperable standard for basic presence- and 116 messaging- functionality, under the name "PIP", for "Presence 117 Information Protocol(s)". Efforts are underway to formally 118 enumerate the requirements such a standard should meet, 119 investigate the applicability of existing technologies and 120 standards, and initiate an IETF working group focused on this 121 area. 123 PIP/0.2 is a demonstration protocol designed as a testbed 124 for certain ideas about meeting "Presence Information Protocol" 125 requirements in a straightforward, interoperable fashion. 126 Drawing from earlier proposals in this area, PIP/0.2 aims to: 128 1) Enable basic "presence information" sharing 129 2) Enable simple text messaging; and 130 3) Remain easy to understand and implement 132 PIP/0.2 specifically makes NO attempt to be: 134 1) Secure 135 2) Scalable/efficient; or 136 3) Rigorously specified 138 The authors intend to demonstrate test software, independently 139 developed by their respective companies, which interoperates 140 based on this protocol, but such PIP/0.2 software should not be 141 considered indicative of any actual product offerings. 143 PIP/0.2 aims to demonstrate end-user to end-user 144 interoperability, without mandating a particular split of 145 responsibility between client and server. In particular, it 146 should be acceptable for a client to subscribe directly to 147 an alien server, use a native server as a proxy to an alien 148 server, or any mixture of the two. This flexibility is 149 possible because the alien server doesn't really care 150 whether a subscription is "really" from a client, it just 151 manages the subscription and delivers the notifications 152 regardless. 154 At the time of this writing, individual implementations of this 155 protocol are underway but full functionality and interoperability 156 have not yet been confirmed by intervendor testing. Thus lessons 157 from further implementation and testing may continue to 158 incrementally alter the specifics of this protocol, beyond 159 what is documented here. 161 5. Naming 163 Resources which represent people or the means of messaging 164 them are identified via URLs. These URLs have the protocol 165 identifier 'pip'. For example, "pip://pip.lotus.com/JR_Ewing". 166 These URLs serve both to identify system principals and to 167 describe network locations where messages may be directed. 169 While identity URLs may serve as the default location at which 170 to attempt certain communication tasks, alternate temporary 171 URL locations are often used instead. For example, the person 172 "pip://pip.lotus.com/JR_Ewing" may actually request that any 173 subscriptions he begins deliver their information to 174 "pip://dallas.xyz.lotus.com/", and that any attempts to 175 instantly message him be directed to 176 "pip://dallas.xyz.lotus.com/iibox". 178 For this version of the demonstration protocol, PIP URLs 179 are always case-insensitive. Otherwise, they follow the 180 conventions of the URL "Common Internet Scheme Syntax" 181 described by RFC 1738. 183 6. Message format 185 All messages follow the formats established for HTTP/1.1 186 [HTTP/1.1]. The protocol identifier for messages compliant with 187 this demo protocol must read "PIP/0.2". 189 7. Transport 191 For this demo protocol, all transactions will be possible 192 through short-lived TCP hits, on which a single request and 193 response complete before the connection is closed. 195 HTTP/1.1-style pipelining MAY be implemented; since that 196 mechanism requires agreement by both sides to keep the 197 connection open, the added capability of some programs to 198 pipeline should not cause any problems for programs unable to 199 pipeline. 201 The default port for PIP/0.2 transactions is 321 [IANA]. 203 8. Character Encoding 205 Request-lines, response lines, and headers must be encoded as 206 per HTTP/1.1. Character encodings for the content of PRESENCE 207 updates and instant-messages (as defined in Section 14) are 208 assumed UTF-8 (Unicode) as a default. Other encodings may be 209 specified by "charset" attribute in Content-type as in the 210 example below. 212 Content-Type: text/plain; charset="ISO-2022-JP" 214 9. Methods 216 9.1 SUBSCRIBE 218 The SUBSCRIBE method is used to express a persistent interest 219 in a remote resource, including any changes which occur at that 220 resource, or notifications which are delivered at that resource. 221 If a SUBSCRIBE request includes a 'Subscription-ID' header, it 222 serves to renew an existing subscription, and should also 223 include a 'Renew-Duration' header. 225 A SUBSCRIBE request should include a 'From' header, 226 identifying the principal (by PIP URL) who is requesting a 227 subscription. It may include a 'Sendback' header, describing 228 the PIP location to which the series of NOTIFYs which may follow 229 on this subscription must be directed. A SUBSCRIBE request may 230 include a 'Duration' header, which indicates the length of time 231 the subscriber would like the subscription to persist even in 232 the absence of any notification or renewal traffic. 234 A SUBSCRIBE request which succeeds will generate a 201 235 Created response, and must include a 'Duration' header which 236 dictates how long the subscription will persist in the absence 237 of traffic. It will include a 'Subscription-ID' header giving 238 the subscription a unique name at the providing resource. The 239 response content will be the current visible state of the 240 target resource. 242 9.2 UNSUBSCRIBE 244 The UNSUBSCRIBE method ends a previously established 245 subscription. It must include a 'Subscription-ID' identifying 246 the subscription to be cancelled. It may either be sent by 247 the subscriber or the publisher. 249 An UNSUBSCRIBE request from a publisher may include a 250 'Location' header, indicating an alternate place to 251 attempt the subscription, now that this subscription has 252 ended. (See part 10, Redirections.) 254 9.3 CHANGE 256 The CHANGE method is used to alter the content stored at 257 a given resource. This will result in NOTIFYs to subscribers 258 of that resource, and at least a temporary change in the 259 stored content of the resource at its server. 261 A CHANGE request may include a 'Duration' header, which 262 indicates that rather than replacing the current permanent 263 value of the resource, it instead provides an 'overlay' 264 or 'lease' for the given duration. Until that period expires, 265 the 'lease value' is the only one visible to external 266 operations. 268 Only one 'lease' may be active for a resource at once; the 269 most recent always takes precedence. A CHANGE that replaces 270 content with identical content still generates NOTIFYs. 272 9.4 NOTIFY 274 The NOTIFY method is used (1) to report CHANGEs inside a 275 subscription; and (2) to deliver arbitrary content to a 276 resource, outside a subscription, for potential acceptance 277 or relay; and (3) to relay a NOTIFYs inside a subscription. 279 When used to report CHANGEs, NOTIFYs are delivered to the 280 subscriber's 'Sendback' location, with a 'From' header 281 describing the resource that CHANGEd, a 'Subscription-ID' 282 header, and a 'Notify-class' header value of 'value'. The 283 recipient must acknowledge the receipt of a NOTIFY 284 on a valid subscription with a 200 OK response. 286 When used to deliver arbitrary content to a resource, the 287 NOTIFY request should include a 'From' header describing the 288 principal who initiated the notification and a 'Notify-class' 289 header with a value of 'transient'. Such NOTIFYs must not 290 have a 'Subscription-ID' header. If the NOTIFY can be 291 meaningfully accepted or relayed, it must generate 292 a 200 OK response; if it cannot be currently relayed (for 293 example no current subscribers to a valid resource) a 294 505 service unavailable response is appropriate. 296 When used to relay a delivery of arbitrary content to 297 a resource, inside a subscription to that resource, a 298 NOTIFY request must include a 'Subscription-ID' and 299 a 'Notify-class' header with a value of 'transient'. 300 The 'From' header provided by the original NOTIFY 301 initiator must be reported in an 'Origin' header, 302 and a new 'From' header describing the relaying 303 resource must be inserted. The recipient must acknowledge 304 the NOTIFY with a 200 OK (unless an error occurs). 306 A NOTIFY which reports something that occurred 307 inside a subscription (that is, meaning (1) or (3) 308 above) always has a 'Subscription-ID' header and 309 must not be treated as if it were a NOTIFY 310 delivering arbitrary content to a resource (meaning 311 (2)). Thus, a NOTIFY coming from one subscription, 312 going to a specific PIP resource, cannot generate 313 further NOTIFYs on other subscriptions to that 314 intermediate resource. 316 9.5 FETCH 318 The FETCH method is used to retrieve the current content 319 of a resource without beginning a subscription. (It is 320 essentially HTTP's GET, differently named to avoid any 321 mistaken impressions that it yet supports all GET facilities -- 322 such as 'If-Modified-Since', etc.) 324 A successful response to a FETCH uses the 200 OK response 325 and includes as content the content of the targetted 326 resource. 328 10. Response Codes 330 PIP/0.2 reuses HTTP/1.1 response codes whenever appropriate. 332 A 404 Not Found response is appropriate when a request 333 with a 'Subscription-ID' identifies a subscription unknown 334 to the recipient, even if the resource identified by the 335 Request-URI can be found. 337 Software should follow HTTP/1.1 conventions when determining 338 whether an request which generated an error may be retried. 340 The 412 Precondition Failed response is used when certain 341 unsupported or currently inappropriate headers appear on 342 a request. This is not precisely the same meaning of that 343 response as in HTTP/1.1. 345 11. Headers 347 Any HTTP/1.1 headers may be included, however, only those 348 listed or described here are guaranteed to have meaning 349 to PIP/0.2 interoperable programs. 351 11.1 Headers Adopted from HTTP/1.1 Without Change: 353 Host 354 Location 355 User-Agent 356 Content-Type 357 Content-Length 359 11.2 Duration 361 An integer second count; used in SUBSCRIBE requests to 362 suggest a subscription lifetime; used in SUBSCRIBE responses 363 to dictate a subscription lifetime; used in CHANGE requests 364 to request a lease lifetime; used in CHANGE responses to 365 dictate a lease lifetime. 367 11.3 Renew-Duration 369 An integer second count; used in CHANGE requests and 370 SUBSCRIBE requests to request renewal of an existing lease 371 or subscription for the given period. 373 11.4 From 375 Identifies the principal/resource originating a request or 376 response. May appear almost anywhere. 378 11.5 Origin 380 Identifies the original initiator of a relayed NOTIFY, 381 when the original 'From' gets replaced by the relaying 382 resource's name. 384 11.6 Sendback 386 Used in SUBSCRIBE requests to specify a delivery location 387 for in-subscription notifications ifferent from the default 388 identity location of the subscriber. 390 11.7 Subscription-ID 392 A token uniquely identifying a subscription at a publishing 393 resource. Used in the response to an initial SUBSCRIBE to give 394 the subscription a name to be referred to later. Used in 395 NOTIFYs to identify what subscription they concern. Used in 396 renewing SUBSCRIBES to specify a subscription to renew. 398 A Subscription-ID is a 'token' as defined in the HTTP/1.1 399 specification. 401 11.8 Notify-class 403 Used in NOTIFY requests to distinguish those reporting CHANGEs 404 from those reporting arbitrary content relaying. May have 405 values of 'value' or 'transient'. 407 11.9 Regarding 409 May be used to indicate a method applies to something other 410 than the main content of a resource. Acceptable values are 411 "content" and "control"; if absent, a value of "content" 412 (default behavior) is implied. If a header specifying 413 "Regarding: control" appears on a request and the recipient 414 of that request does not offer remote-resource-control, a 415 response of 412 Precondition Failed should be returned. 417 When "Regarding: control" appears on a CHANGE, it changes 418 the control-info for a resource, rather than its content. 419 (This may subsequently affect the behavior of that resource 420 as described elsewhere.) When "Regarding: control" appears 421 on a FETCH, the returned content should be the control-info 422 for the given resource rather than the content. When 423 "Regarding: control" appears on a SUBSCRIBE, a subscription 424 should be granted which reports on the status of the 425 control-info rather than the content. NOTIFYs on such a 426 subscription should also have a "Regarding: control" header 427 line. 429 12. Leases 431 Leases are established by issuing a CHANGE request on 432 a resource with a 'Duration' header. The 'Duration' 433 value included with the request is the lifetime of the 434 lease, unless the response dictates a different 'Duration'. 435 Only one lease -- the most recently established lease -- 436 exists at a resource at a time. 438 If any leased value has been set, that is the only value 439 visible to outside viewers of that resource (for example, 440 the content of a successful response to a SUBSCRIBE). The 441 expiration of a leased value generates NOTIFYs, even if 442 the permanent value reverted-to is identical to the expiring 443 leased value. 445 CHANGEs without a 'Duration' header change the "permanent" 446 version of a resource. If a current lease is in effect, such 447 a permanent change may generate no NOTIFYs until the lease 448 expires. 450 A lease may be cancelled by issuing another lease with 451 'Duration' zero. Proper usage of leases dictates that the 452 holder of a lease should cancel it explicitly with a CHANGE 453 request with 'Duration' zero as soon as reversion to the 454 permanent value is appropriate. The lease holder should not 455 rely on the immediate or prompt expiration of a lease as a 456 means of revising an obsolete value. 458 A lease may be refreshed by issuing a CHANGE request with 459 a 'Renew-Duration' header. The content of any such request 460 is ignored. That requested lifetime is honored, unless the 461 response to that request dictates a different 'Duration'. 462 If no lease is in effect at the time a renewal is requested, 463 an error response of 412 Precondition Failed should be 464 returned. 466 13. Subscriptions 468 A subscription begins with a SUBSCRIBE request. A subscription 469 definitely ends with any of (1) a matching UNSUBSCRIBE request 470 from the subscriber; (2) an UNSUBSCRIBE request delivered by 471 the publisher to the subscriber; (3) the elapse of a period of 472 time matching the last publisher-specified 'Duration' value, 473 with no successful SUBSCRIBE or NOTIFY traffic on the 474 subscription. 476 An attempt or attempts to deliver a NOTIFY on a subscription 477 which does not receive a 200 OK response may cause the 478 publisher to discard the subscription, but the publisher 479 should attempt continue to try delivering NOTIFYs until the 480 'Duration' otherwise expires. 482 14. Redirections 484 Redirections (302 moved temporarily responses which result 485 in an automatic transaction to an alternate address) are 486 only supported on initial SUBSCRIBES and FETCHes. 488 If the response to an initial SUBSCRIBE includes a 302 moved 489 elsewhere response, the SUBSCRIBE must be tried at the 490 URL suggested in the included 'Location' header. If fulfilled 491 at the given location, it need not be retried at the original 492 location unless the subscription at the alternate location 493 ends. 495 15. Domain Conventions 497 15.1 Presence Information 499 The common format for sharing online status information is a 500 well-formed XML document. The root element of this document 501 must be named 'PRESENCE'. 503 If the user represented by this data is 'online' then the 504 'PRESENCE' root must include a child element named 'ONLINE'. 505 It may include an element named 'OFFLINE' if the user 506 represented is 'offline'. ('OFFLINE' is assumed if neither 507 'ONLINE' or 'OFFLINE' appears.) These elements need not 508 have any content. 510 The following additional pieces of presence information 511 are optional. Any client should gracefully ignore any 512 information inside that it does not understand. 514 The 'ONLINE' element may include child elements named either 515 'AWAY' or 'BUSY' to indicate either absence from the vicinity 516 of the 'ONLINE' terminal (perhaps derived from programmatic 517 idle sensing) or an expressed desire not to be disturbed, 518 respectively. 520 The 'PRESENCE' root may include a child element named 'NOTE' 521 whose content is a free-form textual bulletin about their 522 current status. 524 The 'PRESENT' root may include a child element named 525 'NICKNAME' whose content is the represented user's 526 preferred short-form representation in a user interface. 528 EXAMPLES: 530 The minimum legal presence document indicating that 531 someone is offline is: 533 535 The minimum legal presence document indicating that 536 someone is online is: 538 539 540 542 Using optional entities that all clients need not understand, 543 the following is an indication that someone is online, but 544 away, and "out to lunch": 546 547 548 549 550 out to lunch 551 553 15.2 Messaging 555 Applications must attempt to send instant communications to 556 the entity represented at PIP URL 'X' by executing a NOTIFY to 557 the URL 'X/iibox' (which stands for "instant inbox"). That is, 558 the URL for delivering messages is established by applying a 559 convention to the subscribing URL. If subscribing to an 560 entity at a non-canonical location, the messaging URL must 561 be derived from the current subscribing location. 563 The NOTIFY must include a 'Notify-class' header with the value 564 'transient'. The content-type may be 'text/plain' or 565 'text/html'. It is expected that the URL to which the NOTIFY 566 is sent is either (1) a location which can directly display 567 the message to the intended recipient; or (2) a location to 568 which the intended recipient is SUBSCRIBEd, so that the 569 NOTIFY is effectively relayed to a final destination which 570 can directly display the message to the intended recipient. 572 If the message is adequately delivered to an endpoint which 573 "consumes" the message, the NOTIFY must receive a response 574 of 200 OK. If the location to which the NOTIFY is delivered 575 does not believe message will reach an adequate end 576 destination -- for example, it is an '/iibox' resource at a 577 server, to which the owner of that resource is not currently 578 subscribed, then the NOTIFY must receive an error response, 579 such as 505 Retry later. 581 15.3 Establishing Redirection (Optional) 583 A resource may be set to issue 302 Moved Temporarily 584 redirecting responses to all requests by using the 585 CHANGE request, together with a "Regarding: control" 586 header, to establish redirection instructions for a given 587 remote resource. These instructions should be provided 588 via an an XML document with a single element, a root 589 named 'REDIRECT', whose content is the URL to be 590 provided by redirections. For example: 592 pip://ws0013.activerse.com/ 594 This control-info change may be subject to a lease, just as 595 with content changes. The control-info for a resource may 596 be viewed via a FETCH with a suitable 'Regarding' header, 597 or subscribed-to via a SUBSCRIBE with a suitable 'Regarding' 598 header. 600 16. Proxying 602 PIP applications may adopt an HTTP-like proxying strategy, 603 relaying messages through a local machine by including 604 information about the message's ultimate destination in 605 the Request-URI and/or 'Host' header. 607 However, processes which are the end destination receiving 608 proxied messages need not treat them specially, or even 609 take note that the traffic is proxied. As such, interop 610 demo programs may or may not attempt to implement proxying 611 at their own discretion. 613 Further proxying examples should appear in the transcripts. 615 17. Security 617 Security issues have been explicitly set aside for the 618 purposes of this demo. An eventual standard should include 619 suggested lowest-common-denominator mechanisms for 620 authenticating communicating peers across vendor/security 621 realms (analogous in its contribution to interoperability 622 to HTTP 'Digest' password authntication) as well as a way 623 for stronger authentication/encryption mechanisms to be 624 overlaid by mutual agreement between compatible software. 626 18. Sample Transcripts 628 18.1 Establishing availability through leases & instant-inbox 629 subscription 631 Consider Alice, with PIP URL "pip://pip.fujitsu.com/alice". 632 She begins running a PIP client on her desktop machine, 633 "aardvark.fujitsu.com", which secures local user port 1321 634 for inbound communications. 636 Before doing anything else, she may wish to confirm how the 637 world sees her: 639 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 640 out> FETCH /alice PIP/0.2 641 out> Host: pip.fujitsu.com 643 in< PIP/0.2 200 OK 644 in< Content-type: text/xml 645 in< Content-length: 12 646 in< 647 in< 648 [socket closes] 650 Then, she wants to appear online to the world -- but in case 651 of network or client troubles, she doesn't want this status 652 to persist indefinitely, so she requests a 20-second lease: 654 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 655 out> CHANGE /alice PIP/0.2 656 out> Host: pip.fujitsu.com 657 out> From: pip://pip.fujitsu.com/alice 658 out> Duration: 20 659 out> Content-type: text/xml 660 out> Content-length: 34 661 out> 662 out> 663 out> 664 out> 666 in< PIP/0.2 200 OK 667 in< Duration: 40 668 [socket closes] 670 Note that the server overrode the requested 'Duration' value, 671 perhaps because it wants to limit the frequency of renewal- 672 traffic. (Had the server been maintaining current subscriptions 673 to Alice's resource, her CHANGE would trigger a number of 674 NOTIFYs to subscribers. Examples of that appear later.) 676 Alice also wants to be able to receive instant-messages. By 677 PIP/0.2 conventions, people who want to message her will send 678 a NOTIFY to "pip://pip.fujitsu.com/alice/iibox". So, Alice 679 wants to subscribe to that location, to receive relayed 680 messages: 682 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 683 out> SUBSCRIBE /alice/iibox PIP/0.2 684 out> Host: pip.fujitsu.com 685 out> From: pip://pip.fujitsu.com/alice 686 out> Sendback: pip://aardvark.fujitsu.com:1321 687 out> Duration: 30 689 in< PIP/0.2 201 subscription created 690 in< Duration: 60 691 in< Subscription-ID: aaii 692 [socket closes] 694 Alice is granted the subscription -- again with an altered 695 duration. This subscription-response has no content, although many 696 subscription-granting responses will include the current content 697 of the target resource. 699 Alice is online indefinitely, so shortly before the 40-second 700 content lease expires, she issues a lease renewal, which the server 701 confirms: 703 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 704 out> CHANGE /alice PIP/0.2 705 out> Host: pip.fujitsu.com 706 out> From: pip://pip.fujitsu.com/alice 707 out> Renew-Duration: 40 709 in< PIP/0.2 200 renewed 710 in< Duration: 40 711 [socket closes] 713 Shortly before the 60-second 'iibox' subscription expires, she 714 issues a subscription-renewal as well: 716 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 717 out> SUBSCRIBE /alice/iibox PIP/0.2 718 out> Host: pip.fujitsu.com 719 out> From: pip://pip.fujitsu.com/alice 720 out> Subscription-ID: aaii 721 out> Renew-Duration: 60 723 in< PIP/0.2 200 renewed 724 in< Duration: 60 725 [socket closes] 727 These renewals continue as long as Alice desires to remain 728 online and messageable. Any NOTIFYs delivered on the 729 subscription, confirmed by the subscriber, also serve to renew 730 the subscription for the last reported 'Duration'. 732 When Alice eventually decides to go offline, she should 733 cancel both her leased value and her instant-inbox 734 subscription. (Relying upon eventual expiration of these 735 relationships is discouraged.) 737 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 738 out> CHANGE /alice PIP/0.2 739 out> Host: pip.fujitsu.com 740 out> From: pip://pip.fujitsu.com/alice 741 out> Renew-Duration: 0 743 in< PIP/0.2 200 lease terminated 744 in< Duration: 0 745 [socket closes] 747 [open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321] 748 out> UNSUBSCRIBE /alice/iibox PIP/0.2 749 out> Host: pip.fujitsu.com 750 out> From: pip://pip.fujitsu.com/alice 751 out> Subscription-ID: aaii 753 in< PIP/0.2 200 cancelled 754 [socket closes] 756 18.2 Subscribing to others 758 Assuming Alice is online, she will typically subscribe to a 759 number of colleagues whose online status interests her. Let's 760 assume she is chiefly interested in Bob 761 (pip://pip.microsoft.com/bob) and Carl 762 (pip://pip.activerse.com/carl). She subscribes to Bob: 764 [open TCP from aardvark.fujitsu.com to pip.microsoft.com:321] 765 out> SUBSCRIBE /bob PIP/0.2 766 out> Host: pip.fujitsu.com 767 out> From: pip://pip.fujitsu.com/alice 768 out> Sendback: pip://aardvark.fujitsu.com:1321 769 out> Duration: 60 771 in< PIP/0.2 201 granted 772 in< Subscription-ID: a2b 773 in< Duration: 60 774 in< Content-type: text/xml 775 in< Content-length: 12 776 in< 777 in< 778 [socket closes] 780 ...and then to Carl... 782 [open TCP from aardvark.fujitsu.com to pip.activerse.com:321] 783 out> SUBSCRIBE /carl PIP/0.2 784 out> Host: pip.fujitsu.com 785 out> From: pip://pip.fujitsu.com/alice 786 out> Sendback: pip://aardvark.fujitsu.com:1321 787 out> Duration: 60 789 in< PIP/0.2 201 granted 790 in< Subscription-ID: a2c 791 in< Duration: 60 792 in< Content-type: text/xml 793 in< Content-length: 22 794 in< 795 in< 796 [socket closes] 798 Alice will refresh these subscriptions over time just as she did 799 the subscription to her own instant-inbox resource. 801 Now say Bob comes online. He issues a CHANGE (not shown) like 802 Alice's first change, which results in Alice receiving the 803 following notification, at the 'Sendback' location she 804 specified earlier: 806 [open TCP from pip.microsoft.com to aardvark.fujitsu.com:1321] 807 out> NOTIFY / PIP/0.2 808 out> From: pip://pip.microsoft.com/bob 809 out> Subscription-ID: a2b 810 out> Notify-class: value 811 out> Content-type: text/xml 812 out> Content-length: 31 813 out> 814 out> 816 in< PIP/0.2 200 ok 817 [socket closes] 819 Similarly, if at some later point while online, Bob adds an 820 optional element to offer a free-form glimpse of his 821 current activity, Alice will receive a similar notification: 823 [open TCP from pip.microsoft.com to aardvark.fujitsu.com:1321] 824 out> NOTIFY / PIP/0.2 825 out> From: pip://pip.microsoft.com/bob 826 out> Subscription-ID: a2b 827 out> Notify-class: value 828 out> Content-type: text/xml 829 out> Content-length: 67 830 out> 831 out> 832 out> 833 out> about to head home 834 out> 836 in< PIP/0.2 200 ok 837 [socket closes] 839 When Bob eventually goes offline, Alice will receive a 840 notification returning his state to the original minimal value. 841 Alternatively, if Alice goes offline first, she should if 842 possible explicitly cancel her subscription, like the following: 844 [open TCP from aardvark.fujitsu.com to pip.microsoft.com:321] 845 out> UNSUBSCRIBE /bob PIP/0.2 846 out> Host: pip.microsoft.com 847 out> From: pip://pip.fujitsu.com/alice 848 out> Subscription-ID: a2b 850 in< PIP/0.2 200 cancelled 851 [socket closes] 853 18.3 Instant messaging 855 Assume both Alice and Bob are online, and subscribed to 856 each other, and Alice wants to send Bob a message. She 857 does so by generating a NOTIFY to Bob's instant-inbox: 859 [open TCP from aardvark.fujitsu.com to pip.microsoft.com:321] 860 out> NOTIFY /bob/iibox PIP/0.2 861 out> Host: pip.microsoft.com 862 out> From: pip://pip.fujitsu.com/alice 863 out> Notify-class: transient 864 out> Content-type: text/plain 865 out> Content-length: 42 866 out> 867 out> When do you arrive at the IETF conference? 869 Bob has previously subscribed (not shown) to the resource at 870 "pip://pip.microsoft.com/bob/iibox", in order to receive 871 relayed instant-messages. (If noone was subscribed to this 872 resource, Alice's message attempt above would generate an 873 immediate error, such as 505 Retry later.) Thus, Alice's 874 NOTIFY will be relayed along to the 'Sendback' location Bob 875 specified in his earlier subscription, which we will assume 876 to be "pip://bear.microsoft.com:1321": 878 [open TCP from pip.microsoft.com to bear.microsoft.com:1321] 879 out> NOTIFY / PIP/0.2 880 out> Origin: pip://pip.fujitsu.com/alice 881 out> From: pip://pip.microsoft.com/bob/iibox 882 out> Notify-class: transient 883 out> Subscription-ID: iibb 884 out> Content-type: text/plain 885 out> Content-length: 42 886 out> 887 out> When do you arrive at the IETF conference? 889 in< PIP/0.2 200 ok 890 [socket from pip.microsoft.com to bear.microsoft.com closes] 892 This successful in-subscription delivery allows Alice 893 to receive a confirmation of her message's delivery in 894 response to her initial NOTIFY 896 [on already-open socket from aardvark to pip.microsoft.com] 897 in< PIP/0.2 200 ok 898 [socket from aardvark.fujiotsu.com to pip.microsoft.com closes] 900 18.4 Publishing from elsewhere via redirection 902 Assume now that Carl comes online, using a client and server 903 which allows him to use redirection to publish from a different 904 location when online than when offline. Rather than establishing 905 a lease on the content of his "pip://pip.activerse.com/carl" 906 resource, he establishes a lease on its control-configuration: 908 [open TCP from cat.activerse.com to pip.activerse.com:321] 909 out> CHANGE /carl PIP/0.2 910 out> Host: pip.activerse.com 911 out> From: pip://pip.activerse.com/carl 912 out> Regarding: control 913 out> Duration: 30 914 out> Content-type: text/xml 915 out> Content-length: 49 916 out> 917 out> pip://cat.activerse.com:1321 919 in< PIP/0.2 200 OK 920 in< Duration: 30 921 [socket closes] 923 As a result, for the duration of this control lease, future 924 subscriptions to Carl's canonical URL will be redirected to 925 his current location, at "cat.activerse.com". Assuming Alice 926 is still subscribed at "pip.activerse.com", her subscription 927 will be cancelled by the server: 929 [open TCP from pip.activerse.com to aardvark.fujitsu.com:1321] 930 out> UNSUBSCRIBE / PIP/0.2 931 out> From: pip://pip.activerse.com/carl 932 out> Subscription-ID: a2c 934 in< PIP/0.2 200 cancelled 935 [socket closes] 937 ...which will cause Alice to retry the subscription -- but 938 that attempt will be redirected rather than granted: 940 [open TCP from aardvark.fujitsu.com to pip.activerse.com:321] 941 out> SUBSCRIBE /carl PIP/0.2 942 out> Host: pip.fujitsu.com 943 out> From: pip://pip.fujitsu.com/alice 944 out> Sendback: pip://aardvark.fujitsu.com:1321 945 out> Duration: 60 947 in< PIP/0.2 302 elsewhere 948 in< Location: pip://cat.activerse.com:1321 949 [socket closes] 951 ...and Alice will then subscribe to Carl at the redirected 952 location: 954 [open TCP from aardvark.fujitsu.com to cat.activerse.com:1321] 955 out> SUBSCRIBE / PIP/0.2 956 out> Host: cat.activerse.com 957 out> From: pip://pip.fujitsu.com/alice 958 out> Sendback: pip://aardvark.fujitsu.com:1321 959 out> Duration: 60 961 in< PIP/0.2 201 granted 962 in< Subscription-ID: a2cc 963 in< Duration: 60 964 in< Content-type: text/xml 965 in< Content-length: 32 966 in< 967 in< 968 [socket closes] 970 Future NOTIFYs on this subscription will go direct from 971 "cat.activerse.com" to "aardvark.fujitsu.com:1321". If Alice 972 wishes to instant-message Carl, she will direct that 973 NOTIFY relative to her current subscription for Carl, 974 to "pip://cat.activerse.com:1321/iibox", rather than 975 through any URL at "pip.activerse.com". 977 19. References 979 [HTTP/1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. 980 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 981 Protocol -- HTTP/1.1": 983 http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt 985 [IANA] IANA Protocol Numbers and Assignment Services, Port Numbers 987 http://www.isi.edu/in-notes/iana/assignments/port-numbers 989 20. Author Addresses 991 Gordon Mohr 992 Activerse, Inc. 993 1301 W. 25th St Suite 500 994 Austin, TX 78705 995 gojomo@activerse.com 997 Sonu Aggarwal 998 Microsoft Corporation 999 One Microsoft Way 1000 Redmond, WA 98052-6399 1001 sonuag@microsoft.com 1003 Mark Day 1004 Lotus Development Corporation 1005 55 Cambridge Parkway 1006 Cambridge, MA 02142 1007 Mark_Day@lotus.com 1009 Avshalom Houri 1010 Ubique 1011 Building 18/D, Science Park 1012 POB: 2523 1013 Rehovot 76123, Israel 1014 avshalom@ubique.com 1016 Youji Kohda 1017 Fujitsu Laboratories Ltd. 1018 64 Nishiwaki, Ohkubo-cho 1019 Akashi, 674-8555, Japan 1020 kohda@flab.fujitsu.co.jp 1022 Dave Marvit 1023 Fujitsu Labs America 1024 595 Lawrence Expressway, 1025 Sunnyvale, CA 94086-3922 1026 dave@marvit.org