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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:common-phone"
xmlns:tns="urn:ietf:params:xml:ns:pidf:common-phone"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:simpleType name="call-stateType">
<xs:restriction base="xs:string">
<xs:enumeration value="not-in-call"/>
<xs:enumeration value="dialing"/>
<xs:enumeration value="alerting"/>
<xs:enumeration value="ringing"/>
<xs:enumeration value="in-call"/>
<xs:enumeration value="in-error"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="call-state" type="tns:call-stateType"/>
</xs: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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:pls"
xmlns:tns="urn:ietf:params:xml:ns:pidf:pls"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="pots-line-state" type="tns:pots-line-stateType"/>
<xs:complexType name="pots-line-stateType">
<xs:sequence>
<xs:any namespace="urn:ietf:params:xml:ns:pidf:common-phone"
minOccurs="1" maxOccurs="1"/>
<xs:element name="call-waiting" type="tns:call-waitingType"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="call-waitingType">
<xs:restriction base="xs:string">
<xs:enumeration value="available"/>
<xs:enumeration value="unavailable"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Rosenberg & Peterson Expires December 22, 2003 [Page 6]
Internet-Draft PIDF Phone Extensions June 2003
3.2 Example POTS Line PIDF document
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ph="urn:ietf:params:xml:ns:pidf:pls"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>closed</basic>
<ph:pots-line-state>
<ph:call-state>in-call</ph:call-state>
<ph:call-waiting>available</ph:call-waiting>
</ph:pots-line-state>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:eps"
xmlns:tns="urn:ietf:params:xml:ns:pidf:eps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cps="urn:ietf:params:xml:ns:pidf:common-phone"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:pidf:common-phone"/>
<xs:element name="enterprise-phone-state"
type="tns:enterprise-phone-stateType"/>
<xs:complexType name="enterprise-phone-stateType">
<xs:sequence>
<xs:element name="line" type="tns:lineType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="lineType">
<xs:sequence>
<xs:element name="line-name" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="line-state" type="cps:call-stateType"
minOccurs="1" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Rosenberg & Peterson Expires December 22, 2003 [Page 8]
Internet-Draft PIDF Phone Extensions June 2003
4.2 Enterprise Phone PIDF Document Example
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ph="urn:ietf:params:xml:ns:pidf:eps"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>closed</basic>
<ph:enterprise-phone-state>
<ph:line>
<ph:line-name>Line 1</ph:line-name>
<ph:line-state>not-in-call</ph:line-state>
</ph:line>
<ph:line>
<ph:line-name>Line 2</ph:line-name>
<ph:line-state>not-in-call</ph:line-state>
</ph:line>
<ph:line>
<ph:line-name>Line 3</ph:line-name>
<ph:line-state>ringing</ph:line-state>
</ph:line>
</ph:enterprise-phone-state>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:wireless-phone-state"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:pidf:wireless-phone-state"
xmlns:cps="urn:ietf:params:xml:ns:pidf:common-phone"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:pidf:common-phone"/>
<xs:element name="wireless-phone-state" type="tns:wpsType"/>
<xs:complexType name="wpsType">
<xs:sequence>
<xs:element name="data-state" type="tns:data-stateType" minOccurs="0"/>
<xs:element name="ran" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="tns:ranType">
<xs:attribute name="registered" type="xs:boolean"
use="optional" default="true"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="visited-network" type="xs:string" minOccurs="0"/>
<xs:element name="home-network" type="xs:string" minOccurs="0"/>
<xs:element name="roaming" type="xs:boolean" minOccurs="0"/>
<xs:element name="signal-strength" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="5"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="call-state" type="cps:call-stateType" minOccurs="0"/>
<xs:element name="barred" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="data-stateType">
<xs:restriction base="xs:string">
<xs:enumeration value="not-connected"/>
<xs:enumeration value="connected"/>
Rosenberg & Peterson Expires December 22, 2003 [Page 11]
Internet-Draft PIDF Phone Extensions June 2003
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ranType">
<xs:restriction base="xs:string">
<xs:enumeration value="cdma2000"/>
<xs:enumeration value="gsm"/>
<xs:enumeration value="cdma"/>
<xs:enumeration value="umts-cs"/>
<xs:enumeration value="umts-ps"/>
<xs:enumeration value="amps"/>
<xs:enumeration value="nmt"/>
<xs:enumeration value="pdc"/>
<xs:enumeration value="tdma"/>
<xs:enumeration value="cdpd"/>
<xs:enumeration value="wifi"/>
<xs:enumeration value="gprs"/>
<xs:enumeration value="mobitex"/>
<xs:enumeration value="hs-csd"/>
<xs:enumeration value="iden"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
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
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ph="urn:ietf:params:xml:ns:pidf:wireless-phone-state"
entity="sip:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>closed</basic>
<ph:wireless-phone-state>
<ph:ran registered="true">gsm</ph:ran>
<ph:roaming>true</ph:roaming>
<ph:call-state>in-call</ph:call-state>
</ph:wireless-phone-state>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Common Phone State Namespace</title>
</head>
<body>
<h1>Namespace for Common Phone State</h1>
<h2>urn:ietf:params:xml:ns:pidf:common-phone</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Wireless Phone State Namespace</title>
</head>
<body>
<h1>Namespace for Wireless Phone State</h1>
<h2>urn:ietf:params:xml:ns:pidf:wireless-phone-state</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>POTS Line State Namsepace</title>
</head>
<body>
<h1>Namespace for POTS Line State</h1>
<h2>urn:ietf:params:xml:ns:pidf:pls</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Enterprise Phone State Namsepace</title>
</head>
<body>
<h1>Namespace for Enterprise Phone State</h1>
<h2>urn:ietf:params:xml:ns:pidf:eps</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
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]