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]