SIMPLE                                                    J. Ala-Kurikka
Internet-Draft                                                E. Harjula
Expires: April 8, 2006                                          D. Howie
                                                           M. Ylianttila
                                                           Univ. of Oulu
                                                         October 5, 2005


 PIDFConn: Extension to the Presence Information Data Format (PIDF) for
                    Expressing Connectivity Features
                  draft-ala-kurikka-simple-pidfconn-00

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 April 8, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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, there are limited ways of expressing
   features related to that interface.  PIDFConn defines an extension to



Ala-Kurikka, et al.       Expires April 8, 2006                 [Page 1]

Internet-Draft                  PIDFConn                    October 2005


   PIDF for describing features of connectivities and the cost of using
   services.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology and Conventions  . . . . . . . . . . . . . . .  4
   2.  Expressing Connectivity Features . . . . . . . . . . . . . . .  6
     2.1.  PIDF . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Current PIDF Extensions  . . . . . . . . . . . . . . . . .  6
     2.3.  Extension to PIDF  . . . . . . . . . . . . . . . . . . . .  6
       2.3.1.  Specifying Connectivity Features . . . . . . . . . . .  6
         2.3.1.1.  The <connectivity> element . . . . . . . . . . . .  6
         2.3.1.2.  The <throughput> element . . . . . . . . . . . . .  7
         2.3.1.3.  The <note> element . . . . . . . . . . . . . . . .  7
       2.3.2.  Specifying Cost  . . . . . . . . . . . . . . . . . . .  7
         2.3.2.1.  The <charge> element . . . . . . . . . . . . . . .  7
         2.3.2.2.  The <basic> element  . . . . . . . . . . . . . . .  7
   3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 11
     4.1.  urn:ietf:params:xml:ns:pidf:pidfconn . . . . . . . . . . . 11
   5.  Extending PIDFConn . . . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  URN Sub-Namespace Registration for
           'urn:ietf:params:xml:ns:pidf:pidfconn' . . . . . . . . . . 14
     6.2.  Schema Registration for Schema
           'urn:ietf:params:xml:ns:pidf:pidfconn' . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Future Work Items  . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 23














Ala-Kurikka, et al.       Expires April 8, 2006                 [Page 2]

Internet-Draft                  PIDFConn                    October 2005


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, PIDF 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 April 8, 2006                 [Page 3]

Internet-Draft                  PIDFConn                    October 2005


   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
   would be very difficult because it would basically require predicting
   features of a possibly upcoming connection with an unknown node.
   Thus, PIDFConn currently presents only the maximum theoretical
   throughput of a connectivity.  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.

   Of the different choices (person, device, service) specified in
   [draft-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-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.

1.2.  Terminology and Conventions

   This memo makes use of the vocabulary defined in the IMPP Model



Ala-Kurikka, et al.       Expires April 8, 2006                 [Page 4]

Internet-Draft                  PIDFConn                    October 2005


   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 April 8, 2006                 [Page 5]

Internet-Draft                  PIDFConn                    October 2005


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-model], <tuple> elements represent services.
   Dynamic status resides inside <status>, whereas characteristics
   (attributes of a static nature) appear directly as children of
   <tuple>. [draft-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
   in question.  If a tuple does not include a <contact>, then that



Ala-Kurikka, et al.       Expires April 8, 2006                 [Page 6]

Internet-Draft                  PIDFConn                    October 2005


   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 the maximum theoretical 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 a throughput is not
   applicable, such as when the communication address resolves to a
   phone, a throughput element SHOULD NOT be included.

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.

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 cost may be due to e.g. using a
   mobile operator's data service.  The source of the cost is not
   defined.  The cost may actually be incurred by the service or the
   connectivity. <charge> may contain zero or one <basic> elements
   followed by any number of elements from different namespaces for an
   extended specification of the billing.

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
   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, contacting her would not affect the her billing, so <basic>
   would be 'false'.  Of course, that would also be the case if there



Ala-Kurikka, et al.       Expires April 8, 2006                 [Page 7]

Internet-Draft                  PIDFConn                    October 2005


   was no fee.  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 April 8, 2006                 [Page 8]

Internet-Draft                  PIDFConn                    October 2005


3.  Example

   The following example indicates to a watcher that the presentity
   pres:joe@example.com has two 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 UMTS connection.  The
   first has a 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 throughput of 64 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>
             <caps:mobile/>



Ala-Kurikka, et al.       Expires April 8, 2006                 [Page 9]

Internet-Draft                  PIDFConn                    October 2005


             <caps:fixed/>
           </caps:supported>
         </caps:mobility>
         <pidfconn:connectivity service="sg89ae">
           <pidfconn:throughput>11000</pidfconn:throughput>
           <pidfconn:note>Free panOULU WLAN</pidfconn:note>
         </pidfconn:connectivity>
         <pidfconn:connectivity>
           <pidfconn:throughput>100000</pidfconn:throughput>
           <pidfconn:note>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>64</pidfconn:throughput>
           <pidfconn:note>My UMTS connection</pidfconn:note>
         </pidfconn:connectivity>
       </caps:devcaps>
       <dm:deviceID>mac:3ht73x7376</dm:deviceID>
     </dm:device>

   </presence>

















Ala-Kurikka, et al.       Expires April 8, 2006                [Page 10]

Internet-Draft                  PIDFConn                    October 2005


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: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="1"/>
           <xs:element name="note" type="Note_t" minOccurs="0"/>
           <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="truefalse">
       <xs:restriction base="xs:string">
         <xs:enumeration value="true"/>
         <xs:enumeration value="false"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:element name="charge">
       <xs:annotation>
         <xs:documentation>
           Describes cost.



Ala-Kurikka, et al.       Expires April 8, 2006                [Page 11]

Internet-Draft                  PIDFConn                    October 2005


         </xs:documentation>
       </xs:annotation>
       <xs:complexType>
         <xs:sequence>
           <xs:element name="basic" type="truefalse"
             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 April 8, 2006                [Page 12]

Internet-Draft                  PIDFConn                    October 2005


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 April 8, 2006                [Page 13]

Internet-Draft                  PIDFConn                    October 2005


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
      RFC&rfc.number; [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">RFC&rfc.number;
         [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 April 8, 2006                [Page 14]

Internet-Draft                  PIDFConn                    October 2005


   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 April 8, 2006                [Page 15]

Internet-Draft                  PIDFConn                    October 2005


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 the network interfaces of the presentity's
   devices.  Through these features, the types of network interfaces 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 April 8, 2006                [Page 16]

Internet-Draft                  PIDFConn                    October 2005


8.  Future Work Items

   Future work for PIDFConn includes finding if and how features of
   connectivities could be further modeled in PIDF.  Also the need for
   extending <charge> has to be evaluated.














































Ala-Kurikka, et al.       Expires April 8, 2006                [Page 17]

Internet-Draft                  PIDFConn                    October 2005


9.  References

9.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-model]
              Rosenberg, J., "A Data Model for Presence",
              draft-ietf-simple-presence-data-model-05 (work in
              progress), September 2005.

   [draft-prescaps]
              Lonnfors, M. and K. Kiss, "User Agent Capability Extension
              to Presence Information Data Format (PIDF)",
              draft-ietf-simple-prescaps-ext-04 (work in progress),
              June 2005.

9.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 April 8, 2006                [Page 18]

Internet-Draft                  PIDFConn                    October 2005


              Information Data Format (PIDF)",
              draft-ietf-simple-rpid-09 (work in progress),
              September 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 April 8, 2006                [Page 19]

Internet-Draft                  PIDFConn                    October 2005


Appendix A.  Acknowledgments

   The authors would like to thank the Application Supernetworking
   (All-IP) project partners: the National Technology Agency (TEKES),
   Nokia, TeliaSonera Finland, Elektrobit Group, IBM and Serv-It for
   their financial support and Henning Schulzrinne, Aki Niemi and
   Krisztian Kiss for their feedback on the connectivity modeling idea.












































Ala-Kurikka, et al.       Expires April 8, 2006                [Page 20]

Internet-Draft                  PIDFConn                    October 2005


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


   Douglas Howie
   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 2535
   Email: douglas.howie@ee.oulu.fi
   URI:   http://www.ee.oulu.fi/~douglas












Ala-Kurikka, et al.       Expires April 8, 2006                [Page 21]

Internet-Draft                  PIDFConn                    October 2005


   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 April 8, 2006                [Page 22]

Internet-Draft                  PIDFConn                    October 2005


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 (2005).  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 April 8, 2006                [Page 23]