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]