idnits 2.17.1 draft-rosenberg-impp-pidf-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. ** 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 85: '... MUST define a means for unioning wh...' RFC 2119 keyword, line 87: '... data format MAY define a means for ...' RFC 2119 keyword, line 90: '... Each atom MUST contain a field whic...' RFC 2119 keyword, line 144: '... presence data MAY be ordered based ...' RFC 2119 keyword, line 148: '... Secondly, it is RECOMMENDED that each...' (8 more instances...) 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 (June 15, 2000) is 8713 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 section? '1' on line 578 looks like a reference -- Missing reference section? '2' on line 582 looks like a reference -- Missing reference section? '3' on line 587 looks like a reference -- Missing reference section? '4' on line 592 looks like a reference -- Missing reference section? '5' on line 596 looks like a reference -- Missing reference section? '6' on line 599 looks like a reference -- Missing reference section? '7' on line 604 looks like a reference -- Missing reference section? '8' on line 609 looks like a reference -- Missing reference section? '9' on line 613 looks like a reference -- Missing reference section? '10' on line 618 looks like a reference -- Missing reference section? '11' on line 623 looks like a reference -- Missing reference section? '12' on line 626 looks like a reference -- Missing reference section? 'RFC 2426' on line 491 looks like a reference -- Missing reference section? '13' on line 630 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force IMPP WG 2 Internet Draft Jonathan Rosenberg 3 Dean Willis 4 Robert Sparks 5 Ben Campbell 6 dynamicsoft 8 Henning Schulzrinne 9 Jonathan Lennox 10 Columbia U. 12 Bernard Aboba 13 Christian Huitema 14 David Gurle 15 Microsoft 16 draft-rosenberg-impp-pidf-00.txt 17 June 15, 2000 18 Expires: December, 2000 20 A Data Format for Presence Using XML 22 STATUS OF THIS MEMO 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as work in progress. 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 This document describes an XML based data format for conveying 46 presence information. The format is one instantiation of an abstract 47 presence data model also described here. 49 1 Introduction 51 Presence is (indirectly) defined in RFC2778 [1] as subscription to 52 and notification of changes in the communications state of a user. 53 This communications state consists of the set of communications 54 means, communications address, and status of that user. A presence 55 document is a computer readable piece of data that contains this 56 presence information. Presence documents are conveyed by a presence 57 protocol [2], but may also be conveyed out of bands. The presence 58 documents are useful and complete in and of themselves, and do not 59 rely on information conveyed by their transfer means in order to be 60 useful. 62 It is fundamental to our notion of presence that a single presentity 63 is represented by a multitude of presence user agents (PUAs), each of 64 which generates presence information for a particular subset of the 65 overall presence state of a presentity. This results in the 66 requirement of a definition of an abstract presence data model, which 67 defines how these presence components are combined to yield a 68 complete presence document. This data model is, in fact, independent 69 of the presence data format itself. However, we describe it here so 70 that the document is complete. 72 This presence data format is based on XML. XML has its strengths and 73 weaknesses, and for this reason, we actually define an additional 74 presence data format which is more suited to smaller footprint 75 endpoints [3]. 77 2 Presence Data Model 79 We define presence as a set of atoms. Each atom defines a component 80 of the presence state of a presentity. The presence state of the 81 presentity is defined by taking the union of the current set of 82 atoms. The process of combining presence information from different 83 sources operates on the granularity of atoms; the content of atoms is 84 not examined when performing such merging. Any presence data format 85 MUST define a means for unioning which can be accomplished through 86 syntactic understanding alone of the presence document. A presence 87 data format MAY define a means for unioning based on semantic 88 understanding. 90 Each atom MUST contain a field which defines the presentity for whom 91 the atom represents. This is in support of Requirement 3.1.2 of 92 RFC2779 [4], which defines requirements for presence and instant 93 messaging. 95 Each atom has an opaque identifier, uniquely identifying it. There is 96 no meaning associated with these identifiers. Two atoms are for the 97 same piece of presence state when they identify the same presentity, 98 and when their atoms match through a byte-wise equality check of 99 their identifiers. 101 Each atom also has an expiration time, indicating the lifetime of the 102 data contained within the atom. 104 A subscriber will receive a set of atoms representing the presence 105 for a user. Computation of the complete presence state of that 106 presentity proceeds as follows: 108 o The subscriber records, for each atom, the most recent 109 instance of that atom. Most recent is *not* defined by 110 expiration time, but rather through sequencing provided by the 111 transfer protocol, or temporal ordering of receipt or fetch, 112 if no such sequencing is provided. 114 o If the most recent atom has an expiration time earlier than 115 the current time, that atom is removed completely from the 116 list of atoms contributing to presence. 118 o The subscriber generates the final piece of presence by taking 119 the set of unexpired atoms for the same presentity, and 120 unioning them as defined by the presence format. 122 This fairly simple model of presence data is very flexible. It 123 supports several different usage scenarios: 125 o Presence data can be generated by a single entity, but be 126 transferred only as updates. Each piece of the presence being 127 updated is a single atom. The presentity need only send an 128 atom when it changes, or send an update before it expires. 130 o Presence data can be generated by a single entity, and the 131 entire presence state is transferred on each notification. 133 o Presence data can be generated by several entities, each 134 updating a set of atoms for the presentity. 136 3 Applying the Model to the Presence Protocol 138 When presence documents corresponding to this model are transferred 139 by the presence protocol [2], two issues need to be considered. 141 First, the presence protocol [2] provides sequencing of 142 notifications, through the CSeq header. When two notifications come 143 from the same source (the To, From, and Call-ID are the same), the 144 presence data MAY be ordered based on the CSeq ordering. If the 145 notifications come from different sources, the temporal order of 146 delivery is used to determine ordering. 148 Secondly, it is RECOMMENDED that each atom correspond to a single 149 Contact address in the registrations. Furthermore, the atom 150 identifier SHOULD be computed as the MD5 hash of the URI of that 151 Contact. This allows both server and PUA to know the identifier, so 152 that they can alternately take over generation of updates for the 153 same atom. 155 4 Components of the Document 157 The presence document format defined here is based on XML, and is 158 similar in concept to the proposed PIDF format by Vermeulen [5]. 159 Usage of XML brings several benefits; as presence data is likely to 160 be rendered, the ability to define XSL and CSS documents for 161 displaying of presence is useful. The ability to digitally sign 162 subcomponents of an XML document is also useful. 164 The presence document always contains the top level element 165 "presence," which indicates that the remainder of the document 166 contains presence information. 168 170 The first sub-element of the presence element is the "presentity" 171 element, which identifies the presentity for whom the presence data 172 is being reported. 174 175 177 The presentity tag has a single mandatory attribute, uri, which gives 178 the address of the presentity. The content of the presentity tag is 179 parsed character data giving a human-readable name. 181 This parsed character data may consist of plain text. It may also 182 contain XML mark-up from an XML document type designed to present 183 human-readable content, such as XHTML [6], MathML [7], SVG [8], 184 VoiceXML [9], SMIL [10], etc., when properly marked with an XML 185 namespace identifier. A program interpreting a buddy list SHOULD 186 interpret and display XML markup from an unknown or unsupported XML 187 namespace as it would a document of type "text/xml" with an unknown 188 or unsupported document type declaration. 190 Note that some of the items in this list of document 191 formats are deliberately rather over-the-top; it seems 192 improbable that having a SMIL presentation to describe a 193 presentity would actually be useful. XHTML, however, will 194 likely be common. 196 Following the presentity tag within the presence tag is a list of 197 atoms. 199 4.1 Atoms 201 Atoms are structured as a collection of addresses. These can either 202 be communications addresses, represented by URLs, or a postal 203 address. 205 206 209 The atom element has the mandatory attribute "id", the unique 210 identifier for the group, and the optional attribute "expires" which 211 indicates the time after which the presence data should be considered 212 invalid. The expiration time is expressed as an integral number of 213 seconds since January 1, 1970, 00:00 UTC. 215 A postal address is indicated by the "postal" element, and consists 216 of freeform text: 218 220 It may contain XML markup from some external namespace, as described 221 previously. 223 It would be nice to require an XML format for postal 224 addresses. Does any exist? vCard XML profile or something? 226 Communications addresses are described by the "address" element. 228 229 232 The "address" element has a single mandatory attribute, uri, which 233 gives the URI of the communications address being described. It also 234 has an optional attribute "priority". The priority tag contains an 235 integer that indicates the relative preference of this address over 236 other addresses. It is a floating-point value between 0 and 1, with 1 237 being the highest preference. 239 Within the address tag, several subtags are defined to specify 240 characteristics of the communications address. These tags have the 241 following meanings: 243 status: Status is an indicator, meant for machine consumption, 244 which indicates the status of this communications address. 245 Valid values are "open", which means communications can be 246 attempted to this address, "closed", which means 247 communications cannot be attempted, and "inuse", which 248 means that communications means is currently being actively 249 used with the entity receiving the presence document. For 250 example, if an instant messaging URL is placed in the uri 251 attribute of the address, and the status is "inuse", this 252 means that the user sending the updated presence document 253 is currently typing an instant message to the recipient of 254 the presence document. 256 This enables a recent feature on MSN, which allows you 257 to see when the person you are IMing is currently 258 typing a reply to your IM. 260 261 263 class: The class tag contains either the value "business" or 264 "personal", indicating whether the address is for business 265 or non-business use. There can only be one class tag per 266 address. 268 269 271 duplex: The duplex tag contains one of the values "full", 272 "half", "send-only" and "receive-only". It indicates 273 whether the address can be used for communications in one 274 direction, the other direction, or both. For example, a 275 page would be considered receive-only. There can only be 276 one duplex tag per address. 278 279 281 feature: The feature tag lists features specific to that 282 communications means. For voice addresses, defined values 283 include "voice-mail" and "attendant". There can be more 284 than one feature tag per address. 286 287 289 mobility: The mobility tag indicates whether the terminal with 290 the given communications address is moving around 291 ("mobile") or fixed ("fixed"). There can only be a single 292 mobility tag per address. 294 295 297 note: Note contains freeform text meant for display to the user, 298 indicating some kind of information about the 299 communications address. There can only be one note tag per 300 address. The note tag may contain XML data from a 301 properly-qualified external XML namespace. 303 305 A PIDF document which appears as a top-level XML document is 306 identified with the formal public identifier "-//IETF//DTD RFCxxxx 307 XPIDF 1.0//EN". If this document is published as an RFC, "xxxx" will 308 be replaced by the RFC number. PIDF documents have the MIME type 309 "application/xpidf+xml". 311 The "+xml" component of the type name conforms with the 312 format of XML MIME types introduced by Murata et al [11]; 313 this allows XML-aware but PIDF-unaware rendering tools to 314 display PIDF usefully. 316 A PIDF document embedded as a fragment within another XML document is 317 identified with the XML namespace identifier 318 "http://www.ietf.org/internet-drafts/draft-rosenberg-impp-pidf- 319 00.txt". If this document is published as an RFC, the namespace 320 identifier will be "http://www.rfc-editor.org/rfc/rfcxxxx.txt", where 321 xxxx is the RFC number. 323 Note that the URIs specifying XML namespaces are only 324 globally unique names; they do not have to reference any 325 particular actual object. The URI of a canonical source of 326 this specification meets the requirement of being globally 327 unique, and is also useful to document the format. 329 5 Constructing the union of two presence documents 331 Construction of the union of two presence documents is 332 straightforward. Two presence documents can be unioned only if they 333 both refer to the same presentity. The atoms from each presence 334 document is extracted. If some number of atoms have the same id, the 335 most recent atom is selected. Most recent is defined either by the 336 transfer protocol, or through temporal ordering. A new presence 337 document is then constructed, using the set of atoms obtained from 338 the presence documents. For example, consider presence document A: 340 341 343 344 345 346
347 348
349 350 351 and presence document B: 353 354 356 357 358 359
360 361
362 363 365 The combined document looks like: 367 368 370 371 372 373
374 375
376 377 378
379 380
381 382 384 6 Example 386 The following is an example presence document: 388 389 391 392 393 394
395 396 397 398 399
400
401 402 Send email if I'm not around 403
404 405 407 7 Mapping from SIP Registrations 409 This section discusses how one would map the contents of a SIP 410 REGISTER message into a presence document. 412 Typically, each Contact header in the registration will be a separate 413 atom. That atom will have a single URL, which is the URL from the 414 Contact header. If the registration is not expired, the status is set 415 to open. Once the registration expires, the address is set to closed, 416 and can be removed completely from the presence document at some 417 point in the future. 419 If the UA sending the registration supports caller preferences [12], 420 and has included them in the contact header, they are mapped one to 421 one into their equivalent XML tags described here. 423 8 DTD 425 The following is the DTD for the presence document. 427 429 431 432 434 435 438 440 441 444 445 447 448 450 451 453 454 456 457 459 461 9 Evaluation against Requirements 463 The following section indicates how this proposal meets the 464 requirements outlined in RFC2779 [4]. 466 Requirement 3.1.2: The common presence format MUST include a 467 means to uniquely identify the PRESENTITY whose PRESENCE 468 INFORMATION is reported. This is supported through the 469 presentity tag. 471 Requirement 3.1.3: The common presence format MUST include a 472 means to encapsulate contact information for the 473 PRESENTITY's PRINCIPAL (if applicable), such as email 474 address, telephone number, postal address, or the like. 475 This is supported through the postal and address tags. 477 Requirement 3.1.4: There MUST be a means of extending the common 478 presence format to represent additional information not 479 included in the common format, without undermining or 480 rendering invalid the fields of the common format This is 481 supported through the definitions of new tags for the XML 482 presence document. 484 Requirement 3.1.5: The working group must define the extension 485 and registration mechanisms for presence information 486 schema, including new STATUS conditions and new forms for 487 OTHER PRESENCE MARKUP. This is readily accomplished, 488 although not specified in this version of the document. 490 Requirement 3.1.6: The presence format SHOULD be based on IETF 491 standards such as vCard [RFC 2426] if possible. The format 492 is based on XML, a standard structured data representation 493 used in many IETF standards, and on URLs, also defined by 494 IETF. 496 Requirement 4.4.1: The common presence format MUST define a 497 minimum standard presence schema suitable for INSTANT 498 MESSAGE SERVICES. This is supported through a URL 499 corresponding to an instant message. This URL, as proposed 500 in [13] is of the form sip:user@host;method=SUBSCRIBE. This 501 URL is then included in an address tag. 503 Requirement 4.4.2: When used in a system supporting INSTANT 504 MESSAGES, the common presence format MUST include a means 505 to represent the STATUS conditions OPEN and CLOSED. These 506 statuses are defined here. 508 Requirement 4.4.3: The STATUS conditions OPEN and CLOSED may 509 also be applied to messaging or communication modes other 510 than INSTANT MESSAGE SERVICES. The presence document here 511 applies statuses to any communications means. IM is not 512 treated differently than any other. 514 10 Authors Addresses 516 Jonathan Rosenberg 517 dynamicsoft 518 200 Executive Drive 519 Suite 120 520 West Orange, NJ 07052 521 email: jdrosen@dynamicsoft.com 523 Dean Willis 524 dynamicsoft 525 200 Executive Drive 526 Suite 120 527 West Orange, NJ 07052 528 email: dwillis@dynamicsoft.com 530 Robert Sparks 531 dynamicsoft 532 200 Executive Drive 533 Suite 120 534 West Orange, NJ 07052 535 email: rsparks@dynamicsoft.com 537 Ben Campbell 538 dynamicsoft 539 200 Executive Drive 540 Suite 120 541 West Orange, NJ 07052 542 email: bcampbell@dynamicsoft.com 544 Henning Schulzrinne 545 Columbia University 546 M/S 0401 547 1214 Amsterdam Ave. 548 New York, NY 10027-7003 549 email: schulzrinne@cs.columbia.edu 551 Jonathan Lennox 552 Columbia University 553 M/S 0401 554 1214 Amsterdam Ave. 555 New York, NY 10027-7003 556 email: lennox@cs.columbia.edu 558 Christian Huitema 559 Microsoft Corporation 560 One Microsoft Way 561 Redmond, WA 98052-6399 562 email: huitema@microsoft.com 564 Bernard Aboba 565 Microsoft Corporation 566 One Microsoft Way 567 Redmond, WA 98052-6399 568 email: bernarda@microsoft.com 570 David Gurle 571 Microsoft Corporation 572 One Microsoft Way 573 Redmond, WA 98052-6399 574 email: dgurle@microsoft.com 576 11 Bibliography 578 [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 579 instant messaging," Request for Comments 2778, Internet Engineering 580 Task Force, Feb. 2000. 582 [2] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, 583 J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for 584 presence," Internet Draft, Internet Engineering Task Force, June 585 2000. Work in progress. 587 [3] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, 588 J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A lightweight 589 presence information data format (LPIDF)," Internet Draft, Internet 590 Engineering Task Force, June 2000. Work in progress. 592 [4] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging 593 / presence protocol requirements," Request for Comments 2779, 594 Internet Engineering Task Force, Feb. 2000. 596 [5] C. Vermeulen, "Presence info data format (PIDF)," Internet Draft, 597 Internet Engineering Task Force, Dec. 1999. Work in progress. 599 [6] W. H. W. Group, "XHTML 1.0: The extensible hypertext markup 600 language," W3C Recommendation REC-xhtml1-20000126, World Wide Web 601 Consortium (W3C), Jan. 2000. Available at 602 http://www.w3.org/TR/xhtml1/. 604 [7] P. Ion and R. Miner, "Mathematical markup language (MathML) 1.01 605 specification," W3C Recommendation REC-MathML-19990707, World Wide 606 Web Consortium (W3C), July 1999. Available at 607 http://www.w3.org/TR/REC-MathML/. 609 [8] J. Ferraiolo, "Scalable vector graphics (SVG) 1.0 specification," 610 W3C Working Draft WD-SVG-20000303, World Wide Web Consortium (W3C), 611 Mar. 2000. Available at http://www.w3.org/TR/SVG/. 613 [9] VoiceXML Forum, "Voice extensible markup language (VoiceXML) 614 version 1.0," W3C Note NOTE-voicexml-20000505, World Wide Web 615 Consortium (W3C), May 2000. Available at 616 http://www.w3.org/TR/voicexml/. 618 [10] P. Hoschka, "Synchronized multimedia integration language (SMIL) 619 1.0 specification," W3C Recommendation REC-smil-19980615, World Wide 620 Web Consortium (W3C), June 1998. Available at 621 http://www.w3.org/TR/REC-smil/. 623 [11] M. Murata and S. S. Laurent, "XML media types," Internet Draft, 624 Internet Engineering Task Force, Jan. 2000. Work in progress. 626 [12] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and 627 callee capabilities," Internet Draft, Internet Engineering Task 628 Force, Mar. 2000. Work in progress. 630 [13] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, 631 J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for 632 instant messaging," Internet Draft, Internet Engineering Task Force, 633 June 2000. Work in progress.