Internet DRAFT - draft-ala-kurikka-simple-pidfconn
draft-ala-kurikka-simple-pidfconn
SIMPLE J. Ala-Kurikka
Internet-Draft E. Harjula
Expires: September 7, 2006 M. Ylianttila
Univ. of Oulu
March 6, 2006
PIDFConn: Extension to the Presence Information Data Format (PIDF) for
Expressing Connectivity Features
draft-ala-kurikka-simple-pidfconn-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Presence Information Data Format (PIDF) defines a basic XML
format for presence information. The optional contact element in
PIDF contains a URI that ultimately resolves to a network interface
on some device. Currently, the ways of expressing features related
to that interface are limited. PIDFConn defines an extension to PIDF
for describing features of connectivities and the cost of using
Ala-Kurikka, et al. Expires September 7, 2006 [Page 1]
Internet-Draft PIDFConn March 2006
services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Selecting the most optimal service . . . . . . . . . . 5
1.2.3. Estimating the quality of interaction . . . . . . . . 5
1.2.4. Informing the user . . . . . . . . . . . . . . . . . . 5
1.2.5. Informing the user 2 . . . . . . . . . . . . . . . . . 5
1.2.6. Determining which options to show . . . . . . . . . . 6
1.3. Terminology and Conventions . . . . . . . . . . . . . . . 6
2. Expressing Connectivity Features . . . . . . . . . . . . . . . 7
2.1. PIDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Current PIDF Extensions . . . . . . . . . . . . . . . . . 7
2.3. Extension to PIDF . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Specifying Connectivity Features . . . . . . . . . . . 7
2.3.1.1. The <connectivity> element . . . . . . . . . . . . 7
2.3.1.2. The <throughput> element . . . . . . . . . . . . . 8
2.3.1.3. The <note> element . . . . . . . . . . . . . . . . 9
2.3.2. Specifying Cost . . . . . . . . . . . . . . . . . . . 9
2.3.2.1. The <charge> element . . . . . . . . . . . . . . . 9
2.3.2.2. The <basic> element . . . . . . . . . . . . . . . 9
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 13
4.1. urn:ietf:params:xml:ns:pidf:pidfconn . . . . . . . . . . . 13
5. Extending PIDFConn . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:pidfconn' . . . . . . . . . . 16
6.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:pidfconn' . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Ala-Kurikka, et al. Expires September 7, 2006 [Page 2]
Internet-Draft PIDFConn March 2006
1. Introduction
The Presence Information Data Format (PIDF) [RFC3863] defines a basic
XML format for presenting presence information of a presentity.
Presence tuples [RFC3863][RFC2778] have an optional <contact>
element. The contents of the <contact> element are understood to
refer to a URI [RFC2396]. The URI (later referred to as
communication address) usually presents a way to reach the
presentity, and the address will eventually resolve to some network
interface on a device.
Currently, the ways of expressing the different features of that
network interface in PIDF are limited. There is a priority attribute
to the <contact> element which defines a relative priority over the
other contacts. However, the priority attribute is neither flexible
nor informative enough in all cases. This document specifies an
extension to PIDF with which information related to a communication
address can be expressed. PIDFConn documents are PIDF documents, so
the content type is application/pidf+xml.
1.1. Motivation
The URI in a <contact> element usually specifies a way to contact the
presentity. The scheme of the URI is not constricted by PIDF: it can
be e.g. sip [RFC3261], tel [RFC3966] or im [RFC3860]. The
functionalities are therefore endless and different functionalities
set different requirements, for example, on the network connection.
In any case, the communication address ultimately resolves to a
network interface on a device. In some cases, a PIDF document for a
presentity might contain multiple alternative communication addresses
to reach a presentity or a service related to the presentity. A
presentity could e.g. have separate contact elements for a desktop
computer with a LAN interface and a laptop computer with a wireless
interface. It is also possible that the mapping of a presentity's
single communication address changes over time, e.g. a sip URI could
resolve to a work laptop computer during working hours and to a home
desktop computer in the evenings and during weekends.
Currently, the <contact> elements may only contain a priority
attribute containing a decimal number. The priority is a relative
priority over the others. The priority might be determined by the
presentity's Presence Agent (PA) [RFC3856] that composes a single
PIDF for a presentity, possibly from multiple presence information
sources. Contacts with higher priorities can precede ones with lower
priorities. However, mapping all the different features of a contact
(a network interface) to a single decimal number could prove
difficult. The suitability of a contact can also depend on what a
watcher would like to accomplish, which would be hard to predict by a
Ala-Kurikka, et al. Expires September 7, 2006 [Page 3]
Internet-Draft PIDFConn March 2006
PA. For example, a top-of-the-line wireless interface can have a
better throughput than an old fixed interface, but the fixed
interface could have a smaller delay, jitter and packet loss. Thus,
the contact with the wireless interface could be preferred for large
file transfers whereas it would be inferior for an application
requiring small delays, such as a real-time game.
PIDFConn helps a watcher to select the optimal communication address
to reach the presentity. PIDFConn could also help to decide whether
to wait a while for a more suitable contact to become available, e.g.
the mapping of a communication address to change (and the PIDF to be
updated). A PIDF application can take advantage of the features
offered by PIDFConn, especially if the application has real-time
requirements or e.g. file transfer capabilities.
Connections occur between two or more participants, and information
in PIDF is typically both produced and consumed prior to a connection
between the producer (presentity) and consumer (watcher). Therefore,
including generic QoS parameters such as delay or jitter in PIDFConn
is challenging in that it would basically require predicting features
of a possibly upcoming connection with a node. However, when the
watcher is known, the values can be either estimated or measured. In
the case of theoretical throughput, a watcher can evaluate both his
own and the presentity's maximum throughput and conclude a very rough
estimate of an expected throughput of a possible connection.
Theoretical throughputs do not, however, typically describe practical
values very well.
Of the different choices (person, device, service) specified in
[draft-data-model], specifying connectivity related features falls
under the <device> element. However, [draft-prescaps] further
extends <device> with a <devcaps> element that contains device
capability information. A <mobility> element therein can determine
whether a device is mobile or fixed. If a device only supports
mobility, it can be estimated that the delay might be greater than
with a fixed device. Thereby specifying <mobility> in conjunction
with <throughput> is encouraged, and <throughput> is to be placed
inside <devcaps>.
When choosing the most suitable communication address, it would also
be useful for a watcher to know if it costs the presentity money to
be contacted. Cost is more related to the service, so this falls
under the <tuple> element as specified in [draft-data-model]. One
other possibility would have been the <service-class> element
specified in [draft-rpid] but it is meant only for specifying the
type of delivery mechanism.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 4]
Internet-Draft PIDFConn March 2006
1.2. Use Cases
1.2.1. General
This chapter provides some exemplary use cases that are by no means
inclusive. Instead of being very generic, they try to give the
reader a view on how PIDFConn could be used in specific scenarios.
There could be more purposes of use, and the listed use cases could
be modified and extended.
1.2.2. Selecting the most optimal service
John is at work and he can be reached by two Instant Messaging (IM)
services that are both listed in his PIDF document. He is logged
into the first service with his mobile phone with a low-end
connectivity. John uses the second service with his laptop with a
high-end connectivity.
Alice wants to both have a VoIP session with John and send a large
file to him. Alice's User Agent (UA) reads John's PIDFConn data and
is able to suggest that the large file be sent to John's laptop
whereas the VoIP session be started with John's mobile (as the mobile
is perhaps more likely to stay with John even if he leaves the office
temporarily).
1.2.3. Estimating the quality of interaction
John wants to initiate a remote desktop sharing session with Alice.
John's UA knows that the session will require a lot of bandwidth and
low delays to be user-friendly. Alice's PIDFConn data, however, only
includes a connectivity with low bandwidth and high delay. John's UA
can notify him that the quality of service would probably not be
optimal if John selected the function.
1.2.4. Informing the user
Alice has an ongoing video conference with John. While the video
stream is acceptable at first, it suddenly becomes considerably
jerkier due to John moving outside of a Wireless LAN hotspot (leading
to vertical handover to another connectivity). John's UA also
updates his PIDFConn data accordingly. After receiving the updated
data, Alice's UA can tell Alice why this sudden loss of quality
happened.
1.2.5. Informing the user 2
Alice wants to send a file to her friend John. By interpreting
John's PIDFConn data Alice's UA sees that John is currently using a
Ala-Kurikka, et al. Expires September 7, 2006 [Page 5]
Internet-Draft PIDFConn March 2006
slow and costly mobile data connectivity. Alice selects a large file
to be transferred to John.
Before the file transfer session is initiated, Alice's UA asks her if
she really wants to send the file right now. The UA points out that
the transfer would take long and it would be costly to John, so Alice
decides to abort the file transfer. She can send the file later,
when John is connected through a connectivity that has no charge.
That kind of a connectivity is not currently in use for any services
listed in John's PIDF document but one is still included in the
PIDFConn data.
1.2.6. Determining which options to show
John wants to call Alice. John's UA reads Alice's PIDFConn data and
determines that Alice's current connectivity is not usable for a
video conference. Thus, when John selects Alice in the UA, the video
conference feature becomes disabled, e.g. "grayed out". John can,
however, initiate a text-based or an audio session instead.
1.3. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [RFC2778]. Terms such as COMMUNICATION ADDRESS, PRESENTITY,
PRINCIPAL and WATCHER in the memo are used in the same meaning as
defined therein.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC 2119 [RFC2119].
Ala-Kurikka, et al. Expires September 7, 2006 [Page 6]
Internet-Draft PIDFConn March 2006
2. Expressing Connectivity Features
2.1. PIDF
PIDF contains a <presence> element which consists of one or more
<tuple>s. A <tuple> optionally contains a <contact> element.
Generally, the URI therein defines a means to contact the presentity.
A <tuple> contains a <status> element which is mandatory. <status>
contains an optional child element <basic> which is either 'OPEN' or
'CLOSED'.
2.2. Current PIDF Extensions
According to [draft-data-model], <tuple> elements represent services.
Dynamic status resides inside <status>, whereas characteristics
(attributes of a static nature) appear directly as children of
<tuple>. [draft-data-model] also introduces the <device> element
which is a child of <presence>. There can be zero or more <device>
elements. [draft-prescaps] introduces a <devcaps> element which
appears as a child to <device>. <devcaps> represent capabilities of a
device.
2.3. Extension to PIDF
This XML Schema defines a new XML namespace:
urn:ietf:params:xml:ns:pidf:pidfconn. All elements defined in this
document reside in this namespace.
2.3.1. Specifying Connectivity Features
This section describes how details of available connectivities are
specified with PIDFConn.
2.3.1.1. The <connectivity> element
PIDFConn extends the <devcaps> element in [draft-prescaps] in
urn:ietf:params:xml:ns:pidf:caps namespace with a <connectivity>
element. <connectivity> defines features of a connectivity of a
device. Devices may have zero or more connectivities. Therefore
there may also be zero or more <connectivity> elements inside a
<devcaps> element. Connectivities that are currently not in use MAY
be included.
<connectivity> has an attribute: 'service'. 'service' MUST be
specified for a connectivity that the device currently uses for a
service that is included in the presence document as one of the
<tuple> elements. The value of 'service' is equivalent to the id of
the <tuple> whose <contact> URI ultimately routes to the connectivity
Ala-Kurikka, et al. Expires September 7, 2006 [Page 7]
Internet-Draft PIDFConn March 2006
in question. Note that the 'service' attribute is required even
though the document includes <deviceID> elements specified by
[draft-data-model]. The device could have multiple connectivities,
so the <deviceID> does not always explicitly refer to a specific
connectivity. In some cases, the document might also include
information about connectivities not currently in use. The 'service'
attribute provides an explicit mapping between connectivities and
services.
If a tuple does not include a <contact>, then that tuple's id MUST
NOT be the value of any <connectivity> element's 'service' attribute.
<connectivity> can have zero or one <throughput> elements and zero or
more <note> elements followed by any number of elements from
different namespaces for reasons of extensibility.
2.3.1.2. The <throughput> element
The <throughput> element specifies throughput in kilobits per second.
In case of asymmetric connections, the minimum of the outbound and
inbound throughputs is used. The value of the element MUST be a non-
negative integer number. Note that bits per second (bps) equals
bytes per second (Bps) multiplied by 8. Examples: 11000 (11 Mbps),
256 (256 kbps). If throughput is not applicable for a connectivity,
the corresponding <connectivity> element SHOULD NOT include a
<throughput> element.
The <throughput> element has a mandatory attribute called 'range'.
The value of the attribute is either 'local' or 'e2e'. Value 'local'
means that the specified throughput is the maximum theoretical
throughput of the connectivity.
The throughput value can also describe the throughput of the second
link, e.g. in the case where it is known that the first link is not
the bottleneck of the connection to the Internet, see Figure 1.
11 Mbps 256 kbps
WLAN ADSL
/---^---\/------------^------------\
D-------R-------------------------ISP
Device Router Internet Service Provider
Figure 1
The throughput of the connectivity is 11 Mbps, but in most
circumstances (where the connection goes through the Internet) the
throughput cannot be more than the throughput of the ADSL connection.
Therefore the throughput of the ADSL connection is written in the
<throughput> element with the 'range' attribute set to 'local'.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 8]
Internet-Draft PIDFConn March 2006
The 'range' attribute can also have a value of 'e2e'. This value
describes an estimate of an end-to-end throughput of the connection
to another node. However, that other node is not specified. Also,
the way how the estimate has been derived is out of scope of this
document. The estimation can be based e.g. on measurements, for
which several both active and passive techniques have been
introduced.
'e2e' throughput can be used primarily only when the watcher is
known. The PIDF document could e.g. be transferred directly between
two nodes, and the throughput should then be describe the parameters
of the end-to-end connection between the presentity's device and the
watcher. If the document was on a server, filtering could be used so
that only a specific watcher can read the throughput. Both a 'local'
and 'e2e' throughput can be defined once in one document for a
connectivity.
2.3.1.3. The <note> element
The <note> element contains a string value which MAY be used for a
human writable and readable comment. For example, a <note> might say
"My home ADSL" or "Free panOULU WLAN". When the note is shown to a
human user, the user SHOULD be able to relate the note to the
specific connectivity that the <note> element relates to. There can
be 0 or more <note> elements, so that notes containing different
languages can be included using the 'xml:lang' attribute. There
SHOULD be only one <note> element for each language.
2.3.2. Specifying Cost
This section describes how to specify cost to the presentity.
2.3.2.1. The <charge> element
PIDFConn extends the <tuple> element in urn:ietf:params:xml:ns:pidf
namespace with a <charge> element. It tells about the cost of using
the service to the presentity. The source of the cost is not
defined. The cost may actually be incurred by the service or the
connectivity, e.g. using a mobile operator's data service. <charge>
may contain zero or one <basic> elements followed by any number of
elements from different namespaces for an extended specification of
the charging.
2.3.2.2. The <basic> element
The <basic> element tells whether the presentity has to pay for
receiving and/or sending traffic to/from the service. <basic>
contains a string of either 'true' or 'false'. <basic> specifies
Ala-Kurikka, et al. Expires September 7, 2006 [Page 9]
Internet-Draft PIDFConn March 2006
whether it would cost money to the presentity if a watcher contacted
her using the related communication address. If the presentity had a
flat fee (i.e. a fixed rate not dependent on the amount of use),
contacting her would not affect her billing, so <basic> would be
'false'. Of course, that would also be the case if there was no fee
at all. Watchers MUST interpret <basic> case-insensitively, but
publishers of PIDFs MUST use lowercase letters in <basic> elements.
When <charge> is 'true', the watcher User Agent (UA) software can
e.g. render the contact with a different icon and pop up a
confirmation dialog before establishing a session. A principal can
then choose to use the service by starting a session. Alternatively,
the principal can wait to start a session until the value of <basic>
for the service changes or another service with a <basic> element set
to 'false' becomes available.
One example where a principal might want to delay starting a session
is when a large file transfer should take place and the presentity
can only be reached through a service whose <charge> is 'true'. If
<charge> later becomes 'false', the principal may choose to start a
session. Alternatively, if another service with a <charge> of
'false' that is capable of file transfers becomes available, the
principal can choose to use that service.
Another example is when a principal has a less important matter that
he would perhaps like to share with a presentity. In this case, the
principal might choose to not use an instant messaging service with a
<charge> of 'true'.
The value of <basic> MAY be selected by a principal. However, the
setting could also change automatically (e.g. when roaming into
another mobile operator's network). The principal might choose
'false', even if he has to pay for the use, in order to indicate that
cost is unimportant.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 10]
Internet-Draft PIDFConn March 2006
3. Example
The following example indicates to a watcher that the presentity
pres:joe@example.com is currently connected to two services that have
their own communication addresses, sip:joe@example.com and
im:joe.black@operator.com. Both are open for communication, the
former through a device using a WLAN connection and the latter
through another device using a GPRS mobile data connection. The
first has a maximum theoretical throughput of 11 Mbits per second and
there is either a charge based on flat rate or using it costs nothing
to Joe. The first device also has another connection which is not
currently used for any of the services listed in the document. The
latter, on the other hand, has a maximum theoretical throughput of
171 kbits per second and costs money for Joe to use.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidfconn="urn:ietf:params:xml:ns:pidf:pidfconn"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
entity="pres:joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
<pidfconn:charge>
<pidfconn:basic>false</pidfconn:basic>
</pidfconn:charge>
<contact>sip:joe@example.com</contact>
</tuple>
<tuple id="s2g9af">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:3ht73x7376</dm:deviceID>
<pidfconn:charge>
<pidfconn:basic>true</pidfconn:basic>
</pidfconn:charge>
<contact>im:joe.black@operator.com</contact>
</tuple>
<dm:device id="lap1">
<caps:devcaps>
<caps:mobility>
<caps:supported>
Ala-Kurikka, et al. Expires September 7, 2006 [Page 11]
Internet-Draft PIDFConn March 2006
<caps:mobile/>
<caps:fixed/>
</caps:supported>
</caps:mobility>
<pidfconn:connectivity service="sg89ae">
<pidfconn:throughput range="local">11000</pidfconn:throughput>
<pidfconn:note xml:lang="en">Free panOULU WLAN</pidfconn:note>
</pidfconn:connectivity>
<pidfconn:connectivity>
<pidfconn:throughput range="local">100000</pidfconn:throughput>
<pidfconn:note xml:lang="en">Fixed Ethernet connection</pidfconn:note>
</pidfconn:connectivity>
</caps:devcaps>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device>
<dm:device id="phn21">
<caps:devcaps>
<caps:mobility>
<caps:supported>
<caps:mobile/>
</caps:supported>
<caps:notsupported>
<caps:fixed/>
</caps:notsupported>
</caps:mobility>
<pidfconn:connectivity service="s2g9af">
<pidfconn:throughput range="local">171</pidfconn:throughput>
<pidfconn:note xml:lang="en">My GPRS data connection</pidfconn:note>
</pidfconn:connectivity>
</caps:devcaps>
<dm:deviceID>mac:3ht73x7376</dm:deviceID>
</dm:device>
</presence>
Ala-Kurikka, et al. Expires September 7, 2006 [Page 12]
Internet-Draft PIDFConn March 2006
4. XML Schema Definitions
The PIDFConn XML schema is shown below. Due to limitations in
composing schemas, not all XML documents that validate against the
schema are semantically valid PIDFConn documents. The schema allows
each element to appear anywhere in PIDF: the section 'Extension to
PIDF' defines the exact limitations of use for PIDFConn.
4.1. urn:ietf:params:xml:ns:pidf:pidfconn
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:pidfconn"
xmlns="urn:ietf:params:xml:ns:pidf:pidfconn"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/>
<xs:simpleType name="localore2e">
<xs:restriction base="xs:string">
<xs:enumeration value="local"/>
<xs:enumeration value="e2e"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="connectivity">
<xs:annotation>
<xs:documentation>
Defines features of a connectivity.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="throughput" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="2">
<xs:attribute name="range" type="localore2e" use="required"/>
</xs:element>
<xs:element name="note" type="Note_t"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="service" type="xs:ID"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="trueorfalse">
<xs:restriction base="xs:string">
Ala-Kurikka, et al. Expires September 7, 2006 [Page 13]
Internet-Draft PIDFConn March 2006
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="charge">
<xs:annotation>
<xs:documentation>
Describes cost.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="basic" type="trueorfalse"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Ala-Kurikka, et al. Expires September 7, 2006 [Page 14]
Internet-Draft PIDFConn March 2006
5. Extending PIDFConn
To add new elements inside <connectivity> or <charge>, the PIDF
extension process described in [RFC3863] is followed. Such
extensions would use namespace designators as
urn:ietf:params:xml:ns:pidf:ext, where 'ext' is the name of the
extension.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 15]
Internet-Draft PIDFConn March 2006
6. IANA Considerations
6.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:pidfconn'
URI: urn:ietf:params:xml:ns:pidf:pidfconn
Description: This is the XML namespace for XML elements defined by
RFCXXXX [RFC Editor: please replace with RFC number] to describe
specific features of services and connectivities in Presence
Information Data Format (PIDF) in the application/pidf+xml content
type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Jussi Ala-Kurikka, jussi.ala-kurikka@oulu.fi
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XTML 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>PIDFConn: Extension to the Presence
Information Data Format (PIDF) for Expressing
Connectivity Features</title>
</head>
<body>
<h1>Namespace for PIDFConn extension</h1>
<h2>urn:ietf:params:xml:ns:pidf:pidfconn</h2>
<p>See <a href="URL of published RFC">RFCXXXX
[RFC editor: please replace with RFC number]</a>.</p>
</body>
</html>
END
6.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:pidfconn'
URI: please assign
Registrant Contact: IESG
XML: See Section 'XML Schema Definitions'
Ala-Kurikka, et al. Expires September 7, 2006 [Page 16]
Internet-Draft PIDFConn March 2006
Note that this document does not require a new content type but
inherits the content type from PIDF: application/pidf+xml.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 17]
Internet-Draft PIDFConn March 2006
7. Security Considerations
PIDF information typically exposes sensitive information to others.
All security considerations in [RFC3863] and in [RFC3856] apply. In
addition to standard PIDF information, PIDFConn reveals certain
features concerning services a presentity uses and network interfaces
of the presentity's devices. Through these features, and by
combining information, data that some can regard as private can be
directly or indirectly found. Also, not all presentities want to
reveal if they pay for using a particular connection or the basis for
that payment. Implementing proper filtering is RECOMMENDED, and
special attention SHOULD be paid to protect confidentiality and
integrity, e.g. with the help of S/MIME [RFC3851].
Ala-Kurikka, et al. Expires September 7, 2006 [Page 18]
Internet-Draft PIDFConn March 2006
8. Open Issues
-How could connectivities be further modeled?
-Is there a need to extend <charge>?
-Should traffic class be included? I.e. categories like bulk
transfer, interactive, responsive real-time, bandwidth?
-Could PIDFConn be used for P2P SIP e.g. in finding an optimal
routing scheme?
Ala-Kurikka, et al. Expires September 7, 2006 [Page 19]
Internet-Draft PIDFConn March 2006
9. Changes
-01:
-Introduced use cases
-Added the 'range' attribute to <throughput>
-Added chapters for open issues and changes
-Some minor textual changes throughout
Ala-Kurikka, et al. Expires September 7, 2006 [Page 20]
Internet-Draft PIDFConn March 2006
10. References
10.1. Normative References
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[draft-data-model]
Rosenberg, J., "A Data Model for Presence",
draft-ietf-simple-presence-data-model-07 (work in
progress), January 2006.
[draft-prescaps]
Lonnfors, M. and K. Kiss, "User Agent Capability Extension
to Presence Information Data Format (PIDF)",
draft-ietf-simple-prescaps-ext-06 (work in progress),
January 2006.
10.2. Informative References
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[draft-rpid]
Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Ala-Kurikka, et al. Expires September 7, 2006 [Page 21]
Internet-Draft PIDFConn March 2006
Information Data Format (PIDF)",
draft-ietf-simple-rpid-10 (work in progress),
December 2005.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 22]
Internet-Draft PIDFConn March 2006
Appendix A. Acknowledgments
The authors would like to thank the Application Supernetworking
(All-IP) project partners: the Finnish Funding Agency for Technology
and Innovation (Tekes), Nokia, TeliaSonera Finland, Elektrobit Group,
IBM and Serv-It for their financial support. Authors' thanks go also
to Douglas Howie, Jun-Zhao Sun, Henning Schulzrinne, Aki Niemi and
Krisztian Kiss for their input.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 23]
Internet-Draft PIDFConn March 2006
Authors' Addresses
Jussi Ala-Kurikka
MediaTeam / University of Oulu
Department of Electrical and Information Engineering
Information Processing Laboratory
P.O.BOX 4500
University of Oulu 90014
FI
Phone: +358 8 553 2811
Email: jussi.ala-kurikka@ee.oulu.fi
URI: http://www.mediateam.oulu.fi
Erkki Harjula
MediaTeam / University of Oulu
Department of Electrical and Information Engineering
Information Processing Laboratory
P.O.BOX 4500
University of Oulu 90014
FI
Phone: +358 8 553 2811
Email: erkki.harjula@ee.oulu.fi
URI: http://www.mediateam.oulu.fi
Mika Ylianttila
MediaTeam / University of Oulu
Department of Electrical and Information Engineering
Information Processing Laboratory
P.O.BOX 4500
University of Oulu 90014
FI
Phone: +358 8 553 2531
Email: mika.ylianttila@oulu.fi
URI: http://www.ee.oulu.fi/~over
Ala-Kurikka, et al. Expires September 7, 2006 [Page 24]
Internet-Draft PIDFConn March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ala-Kurikka, et al. Expires September 7, 2006 [Page 25]
