SIMPLE J. Rosenberg Internet-Draft dynamicsoft Expires: December 22, 2003 J. Peterson Neustar June 23, 2003 Extensions to the Presence Information Document Format (PIDF) for Conveying Phone State draft-rosenberg-peterson-simple-pidf-phone-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 22, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document presents extensions to the Presence Information Document Format (PIDF) for representing the state of telephones. This state includes whether the telephone is in a call or not, whether it is registered to the network, whether it is ringing, and so on. Rosenberg & Peterson Expires December 22, 2003 [Page 1] Internet-Draft PIDF Phone Extensions June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Common State Elements . . . . . . . . . . . . . . . . . . . 3 2.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. POTS Line State . . . . . . . . . . . . . . . . . . . . . . 4 3.1 POTS line XML Schema . . . . . . . . . . . . . . . . . . . . 6 3.2 Example POTS Line PIDF document . . . . . . . . . . . . . . 7 4. Enterprise Phone State . . . . . . . . . . . . . . . . . . . 7 4.1 Enterprise Phone XML Schema . . . . . . . . . . . . . . . . 7 4.2 Enterprise Phone PIDF Document Example . . . . . . . . . . . 9 5. Wireless Phone State . . . . . . . . . . . . . . . . . . . . 9 5.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Example Presence Document . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 7.1 URN Sub-Namespace Registrations . . . . . . . . . . . . . . 13 7.1.1 urn:ietf:params:xml:ns:pidf:common-phone . . . . . . . . . . 14 7.1.2 urn:ietf:params:xml:ns:pidf:wireless-phone-state . . . . . . 14 7.1.3 urn:ietf:params:xml:ns:pidf:pls . . . . . . . . . . . . . . 15 7.1.4 urn:ietf:params:xml:ns:pidf:eps . . . . . . . . . . . . . . 16 7.2 Schema Registrations . . . . . . . . . . . . . . . . . . . . 16 7.2.1 Common Phone State . . . . . . . . . . . . . . . . . . . . . 16 7.2.2 POTS Line State . . . . . . . . . . . . . . . . . . . . . . 16 7.2.3 Enterprise Phone State . . . . . . . . . . . . . . . . . . . 17 7.2.4 Wireless Phone State . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . 20 Rosenberg & Peterson Expires December 22, 2003 [Page 2] Internet-Draft PIDF Phone Extensions June 2003 1. Introduction The Presence Information Document Format (PIDF) [6] provides a baseline set of presence information that allows a presentity [7] to inform a watcher about itself. Information about a presentity is broken into a set of tuples. Each tuple represents a point of contact for a presentity. The tuple includes a URI that can be used to reach the presentity, a basic status of either open or closed, and a textual note meant for consumption by a human. PIDF is meant to be extended to provide additional information about presentities. In this specification, we define extensions to PIDF that allow a tuple to represent a telephone, or any device with telephone-like behaviors. Specifically, a telephone is any piece of hardware or software that is capable of making and/or receiving real time media streams with another such device. Most telephones in the world today lack Internet connections, and communicate only through the Public Switched Telephone Network (PSTN). The presence for telephones described in this document might therefore be created by a telephone switch or other agent responsible for managing dumb telephones when the telephones themselves lack the intelligence to generate or disseminate presence information. That much said, these presence extensions are also servicable for representing Internet telephones. 2. Common State Elements While the presence states associated with wireless phones, POTS phones and enterprise PBX phones do vary, there are certain pieces of presence state that are common to all. In particular, the notion of call state is common across all three types. As such, we specify a common XML schema for describing call state. The namespace URI for elements that represent common presence state across phones is a URN [3], using the namespace identifier 'ietf' defined by [4] and extended by [5]. This URN is: urn:ietf:params:xml:ns:pidf:common-phone-state The elements defined in this schema are: call-state: This element indicates the state of any calls made by, or received by, the phone. The possible values of this element are: not-in-call: The phone is not in a call. Rosenberg & Peterson Expires December 22, 2003 [Page 3] Internet-Draft PIDF Phone Extensions June 2003 dialing: The phone is attempting to initiate a call. This state includes the entry of digits by the user and the subsequent signaling into the network. ringing: The phone has initiated a call, and has received ringback from the called party. alerting: The phone has received a call, and is alerting the user. in-call: The phone is in an active call. in-error: The call could not be completed because of some kind of error, such as all-circuits-busy. 2.1 XML Schema 3. POTS Line State Plain Old Telephone Service (POTS) is a term used to denote the lowest common denominator of functionality among end terminals in the PSTN. A POTS phone (or "black" phone in common parlance) is usually a device with a numeric (multifrequency or rotary) user interface which may or may not support a visual display. POTS devices are not intelligent endpoints - their primary function is to render and receive audio information (in the form of dialing Rosenberg & Peterson Expires December 22, 2003 [Page 4] Internet-Draft PIDF Phone Extensions June 2003 information, human speech or other audible tones) over their connection to a telephone switch. As such, a POTS phone by definition cannot create a presence document and communicate it to the switching infrastructure. The telephone switch to which a POTS phone connects, however, could create a presence document representing the state of the line. Due to the nature of POTS lines, the switching infrastructure has no reliable way to determine whether zero, one or more terminals have been connected to a single telephone line - thus a presence document generated by the switching infrastructure cannot be know with any certainty to correspond to a particular telephone. As such, we term it "POTS line state" rather than "POTS phone state". To integrate the call state of a POTS line into PIDF, we specify a two elements that extend the status element of baseline PIDF: call-state: This element indicates the state of any calls made by, or received by, the phone. call-waiting: This element is used when the call state is 'in-call' only. It signifies whether or not the call is progress is interruptable by call waiting. If the call is interruptable, the value of this element should be "available". If the call waiting feature is not available on the line, or is already occupied by another caller, the value of this element should be "unavailable". If this element is not present, and the call state is 'in-call', the value is assumed to be "unavailable". Rosenberg & Peterson Expires December 22, 2003 [Page 5] Internet-Draft PIDF Phone Extensions June 2003 3.1 POTS line XML Schema Rosenberg & Peterson Expires December 22, 2003 [Page 6] Internet-Draft PIDF Phone Extensions June 2003 3.2 Example POTS Line PIDF document closed in-call available tel:+09012345678 4. Enterprise Phone State Many enterprise telephone networks utilize private branch exchanges (PBXs) that allow phones more functionality than Plain Old Telephone Service. PBXs typically have a signaling interface to a telephone switch that runs over an ISDN Primary Rate Interface (PRI) line, rather than the audio interface supported by a blackphone. Many enterprise phones themselves also have digital signalling interfaces to the PBXs. As a result, many enterprise phones can support multiple lines, call transfer capabilities and other sophisticated features. Moreover, many private branch exchange switches have an integrated voicemail capability for all connected terminals. [[EDITOR's NOTE: Need more input on enterprise devices.]] call-state: This element indicates the state of any calls made by, or received by, the phone. 4.1 Enterprise Phone XML Schema Rosenberg & Peterson Expires December 22, 2003 [Page 7] Internet-Draft PIDF Phone Extensions June 2003 Rosenberg & Peterson Expires December 22, 2003 [Page 8] Internet-Draft PIDF Phone Extensions June 2003 4.2 Enterprise Phone PIDF Document Example closed Line 1 not-in-call Line 2 not-in-call Line 3 ringing tel:+09012345678 5. Wireless Phone State Wireless phones refer to mobile devices that have no wired connection to a network, and can change their attachment point to the network at any point (including while a user is in the middle of a call). This includes phones on the GSM, CDMA, TDMA, GPRS, CDMA2000, and WCDMA networks, along WiFi phones as well. Some of these devices do not support data interfaces to the network, and therefore may not be able to directly publish their own state to a presence agent (many do support SMS, which can be used as a vehicle for published presence state). However, most aspects of the phone state can be derived from network elements, such as the Home Location Register (HLR) and Visiting Location Register (VLR). We therefore focus on state derivable by these entities. Wireless phone status is represented by several XML elements. The namespace URI for elements that represent wireless phone state is a Rosenberg & Peterson Expires December 22, 2003 [Page 9] Internet-Draft PIDF Phone Extensions June 2003 URN [3], using the namespace identifier 'ietf' defined by [4] and extended by [5]. This URN is: urn:ietf:params:xml:ns:pidf:wireless-phone-state We have selected elements which generally represent dynamic state, and which include information that would generally be helpful to a user in deciding whether to make a call. These elements are: barred: This element indicates whether the phone has been barred from registered in the visiting network, due to a lack of roaming agreements or policy that explicitly disallows roaming. call-state: This element indicates the state of any calls made by, or received by, the phone. There is no attempt to support devices which can have multiple calls, each with its own state. data-state: This element indicates whether the phone is connected to a wireless data network, such as GPRS or CDMA1xRTT. The phone is considered connected if, at that time, it is capable of sending and receiving data packets. In some phones, this state is dynamic, since users need to explicitly connect and disconnect. In others, the phone is connected to the data network as long as its registered. The values of this element can be not-connected and connected. ran: This element indicates the current radio access network (RAN) to which the user is connected. The values of this element can be GSM, GPRS, CDMA, CDMA2000, UMTS-PS, UMTS-CS, AMPS, NMT, PDC, TDMA, CDPD, or WiFi, Mobitex, HS-CSD, and IDEN. Additional values can be defined in the future. The "registered" attribute of the element indicates whether the phone has registered on that network. roaming: This element indicates whether or not the phone is currently roaming. It is an XML boolean. home-network: This element is a textual string which indicates the home network provider for the phone. Here, "network provider" refers to the provider of call control and signaling services. visited-network: This element is a textual string which indicates the visited network provider for the phone. Here, "network provider" refers to the provider of call control and signaling services. signal-strength: This element is a number between 0 and 5 which indicates the signal strength for the phone. A 5 means excellent, and a 0 means no signal. This information is likely to change frequently, and it should be included in notifications with great Rosenberg & Peterson Expires December 22, 2003 [Page 10] Internet-Draft PIDF Phone Extensions June 2003 care. 5.1 XML Schema Rosenberg & Peterson Expires December 22, 2003 [Page 11] Internet-Draft PIDF Phone Extensions June 2003 5.2 Example Presence Document The following presence document indicates that the user has a single contact which represents a phone. This is a wireless phone on the GSM network. The phone is roaming, and the user is in a call. The fact that they are in a call results in the basic status being set to closed. Rosenberg & Peterson Expires December 22, 2003 [Page 12] Internet-Draft PIDF Phone Extensions June 2003 closed gsm true in-call tel:+09012345678 6. Security Considerations Phone state, like other presence state, represents sensitive information. It conveys detailed information about what a user is doing, and potentially where they are. Users may therefore wish to have this information hidden from eavesdroppers. Encryption of this presence data is provided by the underlying protocol that carriers this document. It is RECOMMENDED that presence documents conveying phone status only be transported with protocols that can provide encryption. For example, SIP extensions for presence [9] can provide encryption. Users may also wish to control who can have access to phone state information. Users can control the type of information conveyed to watchers of their presence using a data manipulation protocol, as described in [8]. The protocol used for such a purpose is the XML Configuration Access Protocol (XCAP) [10]. An XCAP application usage has been specified for setting authorization policy [11]. This mechanism allows a user to enable or disable access to presence information on a namespace by namespace basis. Therefore, to prevent phone state information from being distributed, users would remove permissions for viewing the namespaces defined in this specification. 7. IANA Considerations There are several IANA considerations associated with this specification. 7.1 URN Sub-Namespace Registrations Rosenberg & Peterson Expires December 22, 2003 [Page 13] Internet-Draft PIDF Phone Extensions June 2003 This section registers three new XML namespaces, as per the guidelines in [5]. 7.1.1 urn:ietf:params:xml:ns:pidf:common-phone URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:common-phone-state. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). XML: BEGIN Common Phone State Namespace

Namespace for Common Phone State

urn:ietf:params:xml:ns:pidf:common-phone

See RFCXXXX.

END 7.1.2 urn:ietf:params:xml:ns:pidf:wireless-phone-state URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:wireless-phone-state. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). XML: Rosenberg & Peterson Expires December 22, 2003 [Page 14] Internet-Draft PIDF Phone Extensions June 2003 BEGIN Wireless Phone State Namespace

Namespace for Wireless Phone State

urn:ietf:params:xml:ns:pidf:wireless-phone-state

See RFCXXXX.

END 7.1.3 urn:ietf:params:xml:ns:pidf:pls URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:pls. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML: BEGIN POTS Line State Namsepace

Namespace for POTS Line State

urn:ietf:params:xml:ns:pidf:pls

See RFCXXXX.

END Rosenberg & Peterson Expires December 22, 2003 [Page 15] Internet-Draft PIDF Phone Extensions June 2003 7.1.4 urn:ietf:params:xml:ns:pidf:eps URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:eps. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML: BEGIN Enterprise Phone State Namsepace

Namespace for Enterprise Phone State

urn:ietf:params:xml:ns:pidf:eps

See RFCXXXX.

END 7.2 Schema Registrations This specification registers four schemas, as per the guidelines in in [5]. 7.2.1 Common Phone State URI: please assign. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML: The XML can be found as the sole content of Section 2.1. 7.2.2 POTS Line State Rosenberg & Peterson Expires December 22, 2003 [Page 16] Internet-Draft PIDF Phone Extensions June 2003 URI: please assign. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML: The XML can be found as the sole content of Section 3.1. 7.2.3 Enterprise Phone State URI: please assign. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML: The XML can be found as the sole content of Section 4.1. 7.2.4 Wireless Phone State URI: please assign. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). XML: The XML can be found as the sole content of Section 5.1. 8. Acknowledgments The authors would like to thank Rob Allen, Adam Roach and Mark Peck for their comments on this specification. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000. [3] Moats, R., "URN Syntax", RFC 2141, May 1997. [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [5] Mealling, M., "The IETF XML Registry", Rosenberg & Peterson Expires December 22, 2003 [Page 17] Internet-Draft PIDF Phone Extensions June 2003 draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. [6] Fujimoto, S. and H. Sugano, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. Informative References [7] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [8] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", draft-ietf-simple-data-req-02 (work in progress), April 2003. [9] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [10] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-rosenberg-simple-xcap-00 (work in progress), May 2003. [11] Rosenberg, J., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in progress), June 2003. Authors' Addresses Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg & Peterson Expires December 22, 2003 [Page 18] Internet-Draft PIDF Phone Extensions June 2003 Jon Peterson Neustar 1800 Sutter Street Suite 570 Concord, CA 94520 US Phone: +1 925 363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz Rosenberg & Peterson Expires December 22, 2003 [Page 19] Internet-Draft PIDF Phone Extensions June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg & Peterson Expires December 22, 2003 [Page 20] Internet-Draft PIDF Phone Extensions June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg & Peterson Expires December 22, 2003 [Page 21]