summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5196.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5196.txt')
-rw-r--r--doc/rfc/rfc5196.txt1683
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc5196.txt b/doc/rfc/rfc5196.txt
new file mode 100644
index 0000000..2acc499
--- /dev/null
+++ b/doc/rfc/rfc5196.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group M. Lonnfors
+Request for Comments: 5196 K. Kiss
+Category: Standards Track Nokia
+ September 2008
+
+
+ Session Initiation Protocol (SIP) User Agent Capability Extension to
+ Presence Information Data Format (PIDF)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ Presence Information Data Format (PIDF) defines a common presence
+ data format for Common Profile for Presence (CPP) compliant presence
+ protocols. This memo defines a PIDF extension to represent SIP User
+ Agent capabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 1]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Motivation .................................................3
+ 1.2. Scope ......................................................4
+ 2. Conventions .....................................................4
+ 3. Extension for "Indicating User Agent Capabilities in the
+ Session Initiation Protocol (SIP)" in PIDF Documents ............4
+ 3.1. Overview of Operation ......................................4
+ 3.2. Service capabilities .......................................5
+ 3.2.1. <servcaps> Element ..................................5
+ 3.2.2. <audio> Element .....................................5
+ 3.2.3. <application> Element ...............................5
+ 3.2.4. <data> Element ......................................6
+ 3.2.5. <control> Element ...................................6
+ 3.2.6. <video> Element .....................................6
+ 3.2.7. <text> Element ......................................6
+ 3.2.8. <message> Element ...................................7
+ 3.2.9. <type> Element ......................................7
+ 3.2.10. <automata> Element .................................7
+ 3.2.11. <class> Element ....................................7
+ 3.2.12. <duplex> Element ...................................8
+ 3.2.13. <description> Element ..............................8
+ 3.2.14. <event-packages> Element ...........................9
+ 3.2.15. <priority> Element .................................9
+ 3.2.16. <methods> Element .................................10
+ 3.2.17. <extensions> Element ..............................11
+ 3.2.18. <schemes> Element .................................11
+ 3.2.19. <actor> Element ...................................12
+ 3.2.20. <isfocus> Element .................................12
+ 3.2.21. <languages> Element ...............................13
+ 3.3. Device Capabilities .......................................13
+ 3.3.1. <devcaps> Element ..................................13
+ 3.3.2. <mobility> Element .................................14
+ 3.3.3. <description> Element ..............................14
+ 4. Usage Guidelines ...............................................15
+ 4.1. Use of <supported> and <notsupported> Elements ............15
+ 5. Examples .......................................................16
+ 6. XML Schema Definitions .........................................17
+ 7. IANA Considerations ............................................26
+ 7.1. URN Sub-Namespace Registration for ........................26
+ 7.2. Schema Registration for Schema ............................27
+ 8. Security Considerations ........................................27
+ 9. Acknowledgments ................................................27
+ 10. References ....................................................27
+ 10.1. Normative References .....................................27
+ 10.2. Informative References ...................................28
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 2]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+1. Introduction
+
+ Common Profile for Presence (CPP) [RFC3859] and Common Profile for
+ Instant Messaging (CPIM) [RFC3860] define common operations and
+ formats that all presence and instant messaging services must agree
+ upon so that basic interoperability is possible. The actual base
+ format for the presence is defined in the Presence Information
+ Document Format (PIDF) [RFC3863]. The PIDF has been designed to
+ reduce the need for gatewaying and to allow end-to-end security of
+ presence information. It has taken a very minimalistic approach to
+ support such operations. In order to make the PIDF usable by
+ different presence applications, these applications usually must
+ extend the basic PIDF by standard XML mechanisms as defined in PIDF
+ [RFC3863].
+
+ The aim of this memo is to introduce a SIP-specific extension
+ mechanism to the PIDF that conveys the same SIP media feature tags as
+ described in [RFC3840]. With this extension, presence applications
+ based on SIP can have richer and more usable presence information
+ compared to the baseline PIDF.
+
+1.1. Motivation
+
+ The PIDF [RFC3863] defines a <contact> element that may appear once
+ inside every <tuple> element. The content of the <contact> element
+ encodes the CONTACT ADDRESS and CONTACT MEANS as defined in
+ [RFC2778]. The <contact> element is defined to be a URI of any
+ scheme. In some implementations, the URI scheme can uniquely
+ identify the service the tuple intends to describe (e.g., im: URI
+ scheme usually represents Instant Messaging service). However, this
+ may not be the case in all implementations. For example in SIP, a
+ SIP URI scheme can represent different kinds of services. A SIP URI
+ scheme can be used to contact voice services, video services, or
+ messaging services. If it is not known by other means, it might be
+ hard for applications processing the presence information containing
+ only a SIP URI contact addresses to know what particular service the
+ tuple intends to describe. Also, watchers receiving presence
+ information would probably benefit from getting more descriptive
+ information about what particular communication means or services are
+ supported by the presentity.
+
+ The User Agent Capabilities extension [RFC3840] defines a set of
+ extensions that allow user agents to express preferences about
+ request handling in SIP servers. The same information can provide
+ value to watchers as well so that they can make more rational
+ decisions on how a presentity should be contacted if a presence
+ document contained this information.
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 3]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+1.2. Scope
+
+ This document defines a PIDF extension, which enables SIP presence
+ implementations to represent User Agent Capabilities [RFC3840] within
+ presence information.
+
+ This extension does not replace media negotiation mechanisms defined
+ for SIP (e.g., SDP [RFC4566]). The purpose of this extension is for
+ a presentity to give watchers hints about the presentity's
+ preferences, willingness, and capabilities to communicate before
+ watchers initiate communication with the presentity.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ This memo makes use of the vocabulary defined in [RFC2778] and
+ [RFC3863].
+
+3. Extension for "Indicating User Agent Capabilities in the Session
+ Initiation Protocol (SIP)" in PIDF Documents
+
+ This section presents the extension elements, attributes, their
+ values, and semantics. This section also describes how this
+ extension can be further extended.
+
+ This extension is intended to be used within the PIDF [RFC3863] and
+ that particular usage is described here. This extension may also be
+ used with other XML documents if appropriate.
+
+3.1. Overview of Operation
+
+ This document defines how the features presented in [RFC3840] can be
+ provided as part of presence information. Additionally, this memo
+ includes the "type" feature tag [RFC2913], "message" media type
+ feature tag [RFC4569], and the "language" feature tag [RFC4646]
+ definitions. Adding these features to the PIDF means mapping them to
+ an XML formatted structure.
+
+ The presence data model [RFC4479] defines presence information
+ consisting of three types of data elements: person, service, and
+ device. This memo follows this model so that one XML extension is
+ defined to describe device capabilities and another one to describe
+ service capabilities.
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 4]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ The namespace URIs for elements defined by this document are URNs
+ using the namespace identifier 'ietf' defined by [RFC2648] and
+ extended by [RFC3688].
+
+ When these extension namespaces are congregated with the PIDF
+ document, the combined document MUST follow the same general
+ formatting rules as specified in Section 4.1 of [RFC3863].
+
+3.2. Service capabilities
+
+ Elements belonging to service capabilities are used to describe
+ dynamic characteristics of a service. These capabilities are
+ enclosed within the <servcaps> element which SHOULD be located in the
+ PIDF document as a child element of urn:ietf:params:xml:ns:pidf
+ namespace <tuple> [RFC3863] element.
+
+ The namespace identifier for these elements is:
+
+ urn:ietf:params:xml:ns:pidf:caps
+
+3.2.1. <servcaps> Element
+
+ The root element of service capabilities is <servcaps>. The root
+ element always has to be present. This element can contain the
+ following child elements: <audio>, <application>, <data>, <control>,
+ <video>, <text>, <message>, <type>, <automata>, <class>, <duplex>,
+ <description>, <event-packages>, <priority>, <methods>, <extensions>,
+ <schemes>, <actor>, <isfocus>, and <languages> followed by any number
+ of optional extension elements from other namespaces.
+
+ A <servcaps> element can contain any number of optional extension
+ attributes from other namespaces.
+
+3.2.2. <audio> Element
+
+ The <audio> element indicates that the service supports audio as a
+ streaming media type as defined in [RFC3840].
+
+ The <audio> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports audio
+ media type, and the value 'false' indicates that service does not
+ support audio media type.
+
+3.2.3. <application> Element
+
+ The <application> element indicates that the service supports
+ application as a streaming media type as defined in [RFC3840].
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 5]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ The <application> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports
+ application media type, and the value 'false' indicates that service
+ does not support application media type.
+
+3.2.4. <data> Element
+
+ The <data> element indicates that the service supports data as a
+ streaming media type as defined in [RFC3840].
+
+ The <data> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports data
+ media type, and the value 'false' indicates that service does not
+ support data media type.
+
+3.2.5. <control> Element
+
+ The <control> element indicates that the service supports control as
+ a streaming media type as defined in [RFC3840].
+
+ The <control> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports control
+ media type, and the value 'false' indicates that service does not
+ support control media type.
+
+3.2.6. <video> Element
+
+ The <video> element indicates that the service supports video as a
+ streaming media type as defined in [RFC3840].
+
+ The <video> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports video
+ media type, and the value 'false' indicates that service does not
+ support video media type.
+
+3.2.7. <text> Element
+
+ The <text> element indicates that the service supports text as a
+ streaming media type as defined in [RFC3840].
+
+ The <text> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports text
+ media type, and the value 'false' indicates that service does not
+ support text media type.
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 6]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+3.2.8. <message> Element
+
+ The <message> element indicates that the service supports messaging
+ as a streaming media type as defined in [RFC4569].
+
+ The <message> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that service supports message
+ media type, and the value 'false' indicates that service does not
+ support message media type.
+
+3.2.9. <type> Element
+
+ The <type> element indicates a MIME media content type (i.e., that
+ appears in a 'Content-type:' header of the corresponding MIME-
+ formatted data) as defined in [RFC2913].
+
+ The <type> element is a string type and does not have any attributes.
+ It MUST be a string of the form "type/subtype", where 'type' and
+ 'subtype' are defined by the MIME specification [RFC2045]. Only
+ lowercase letters SHOULD be used.
+
+3.2.10. <automata> Element
+
+ The <automata> element indicates whether the service represents an
+ automaton (such as a voicemail server, conference server, or
+ recording device) or a human as defined in [RFC3840].
+
+ The <automata> element is a boolean type and does not have any
+ attributes. The value 'true' indicates that the service represents
+ an automaton, and the value 'false' indicates that it represents a
+ human.
+
+3.2.11. <class> Element
+
+ The <class> element indicates the setting, business or personal, in
+ which a communications service is used as defined in [RFC3840].
+
+ The <class> element can contain two elements: <supported> and
+ <notsupported>. Classes that are supported by the service can be
+ listed under the <supported> element, and classes that are not
+ supported by the service can be listed under the <notsupported>
+ element.
+
+ <supported> and <notsupported> elements can contain <business> and
+ <personal> elements followed by any number of optional extension
+ elements from other namespaces. The semantics of business and
+ personal are defined in [RFC3840] as:
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 7]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ o <business>: The service is used for business communications.
+
+ o <personal>: The service is used for personal communications.
+
+ Any value that is registered with IANA for the SIP media feature tag
+ registration tree as a sip.class media feature tag can be used as a
+ value of an extension element. If the appropriate value is not
+ registered, it SHOULD be registered as defined in [RFC3840].
+
+3.2.12. <duplex> Element
+
+ The <duplex> element lists whether a communications service can
+ simultaneously send and receive media ("full"), alternate between
+ sending and receiving ("half"), only receive ("receive-only"), or
+ only send ("send-only") as defined in [RFC3840].
+
+ The <duplex> element can contain two elements: <supported> and
+ <notsupported>. Duplex modes that are supported by the service can
+ be listed under the <supported> element, and duplex modes that are
+ not supported by the service can be listed under the <notsupported>
+ element.
+
+ <supported> and <notsupported> elements can contain <full>, <half>,
+ <receive-only>, and <send-only> elements followed by any number of
+ optional extension elements from other namespaces. The semantics of
+ these elements are defined in [RFC3840] as:
+
+ o <full>: The service can simultaneously send and receive media.
+
+ o <half>: The service can alternate between sending and receiving
+ media.
+
+ o <receive-only>: The service can only receive media.
+
+ o <send-only>: The service can only send media.
+
+ Any value that is registered with IANA for the SIP media feature tag
+ registration tree as a sip.duplex media feature tag can be used as a
+ value of an extension element. If the appropriate value is not
+ registered, it SHOULD be registered as defined in [RFC3840].
+
+3.2.13. <description> Element
+
+ The <description> element provides a textual description of the
+ service as defined in [RFC3840].
+
+ The <description> element is of string type and does not have any
+ attributes.
+
+
+
+Lonnfors & Kiss Standards Track [Page 8]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ The <description> element SHOULD be labeled with the 'xml:lang'
+ attribute to indicate its language and script. The specification
+ allows multiple occurrences of this elements so that the presentity
+ can convey <description> elements in multiple scripts and languages.
+ If no 'xml:lang' attribute is provided, the default value is
+ "i-default" as defined in [RFC2277].
+
+3.2.14. <event-packages> Element
+
+ The <event-packages> element lists the event packages supported by a
+ service.
+
+ The <event-packages> element can contain two elements: <supported>
+ and <notsupported>. Event packages that are supported by the service
+ can be listed under the <supported> element, and event packages that
+ are not supported by the service can be listed under the
+ <notsupported> element.
+
+ The <supported> and <notsupported> elements can contain any values
+ from the IANA SIP event types namespace registry followed by any
+ number of optional extension elements from other namespaces. As of
+ this writing, the IANA SIP event types namespace registry includes
+ the following packages: <conference>, <dialog>, <kpml>,
+ <message-summary>, <poc-settings>, <presence>, <reg>, <refer>,
+ <Siemens-RTP-Stats>, <spirits-INDPs>, <spirits-user-prof>, and
+ <winfo>.
+
+3.2.15. <priority> Element
+
+ The <priority> element indicates the call priorities the service is
+ willing to handle as defined in [RFC3840].
+
+ The <priority> element can contain two elements: <supported> and
+ <notsupported>. Priority values that are supported by the service
+ can be listed under the <supported> element, and priority values that
+ are not supported by the service can be listed under the
+ <notsupported> element.
+
+ The <supported> and <notsupported> elements can contain any number of
+ <lowerthan>, <higherthan>, <equals>, and <range> elements followed by
+ any number of optional extension elements from other namespaces.
+
+3.2.15.1. <lowerthan> Element
+
+ The <lowerthan> element has a single attribute called "maxvalue".
+ The "maxvalue" attribute is used to give the highest priority value
+ that the service is willing to support. All values equal and below
+ that value are supported.
+
+
+
+Lonnfors & Kiss Standards Track [Page 9]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+3.2.15.2. <higherthan> Element
+
+ The <higherthan> element has a single attribute called "minvalue".
+ The "minvalue" attribute is used to give the lowest priority value
+ that the service is willing to support. All values equal and above
+ that value are supported.
+
+3.2.15.3. <equals> Element
+
+ The <equals> element is used to indicate the exact priority value
+ that the service is willing to handle. The <equals> element has a
+ single attribute called "value". The "value" attribute is used to
+ indicate the exact supported priority value.
+
+3.2.15.4. <range> Element
+
+ The <range> element is used to indicate the priority range that the
+ service is willing to handle. The <range> element has two attributes
+ called "minvalue" and "maxvalue". The value of the "minvalue"
+ attribute indicates the lowest priority value supported by the
+ service, and the value of the "maxvalue" attribute indicates the
+ highest priority value supported by the service.
+
+3.2.16. <methods> Element
+
+ The <methods> element indicates the SIP methods supported by a
+ service. In this case, "supported" means that the service can
+ receive requests with this method. In that sense, it has the same
+ connotation as the Allow header field as defined in [RFC3840].
+
+ The <methods> element can contain two elements: <supported> and
+ <notsupported>. Methods that are supported by the service can be
+ listed under the <supported> element, and methods that are not
+ supported by the service can be listed under the <notsupported>
+ element.
+
+ The <supported> and <notsupported> elements can contain any values
+ from the methods table of the IANA SIP parameters registry table
+ followed by any number of optional extension elements from other
+ namespaces. As of this writing, the IANA SIP parameters registry
+ includes the following methods:<ACK>, <BYE>, <CANCEL>, <INFO>,
+ <INVITE>, <MESSAGE>, <NOTIFY>, <OPTIONS>, <PRACK>, <PUBLISH>,
+ <REFER>, <REGISTER>, <SUBSCRIBE>, and <UPDATE>.
+
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 10]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+3.2.17. <extensions> Element
+
+ The <extensions> element is a list of SIP extensions (each of which
+ is defined by an option-tag registered with IANA) that are understood
+ by the service. Understood, in this context, means that the option
+ tag would be included in a Supported header field in a request as
+ defined in [RFC3840].
+
+ The <extensions> element can contain two elements: <supported> and
+ <notsupported>. Extensions that are supported by the service can be
+ listed under the <supported> element, and extensions that are not
+ supported by the service can be listed under the <notsupported>
+ element.
+
+ The <supported> and <notsupported> elements can contain any values
+ from the option tags table of the IANA SIP parameters registry table
+ followed by any number of optional extension elements from other
+ namespaces. As of this writing, the IANA SIP parameters registry
+ includes the following option tags: <rel100>, <early-session>,
+ <eventlist>, <from-change>, <gruu>, <histinfo>, <join>, <norefersub>,
+ <path>, <precondition>, <pref>, <privacy>, <recipient-list-invite>,
+ <recipient-list-subscribe>, <replaces>, <resource-priority>, <sdp-
+ anat>, <sec-agree>, <tdialog>, and <timer>.
+
+3.2.18. <schemes> Element
+
+ The <schemes> element provides the set of URI schemes that are
+ supported by a service. "Supported" implies, for example, that the
+ service would know how to handle a URI of that scheme in the Contact
+ header field of a redirect response as defined in [RFC3840].
+
+ The <schemes> element can contain two elements: <supported> and
+ <notsupported>. Schemes that are supported by the service can be
+ listed under the <supported> element, and schemes that are not
+ supported by the service can be listed under the <notsupported>
+ element.
+
+ <supported> and <notsupported> elements can contain any number of <s>
+ elements, which can be used to describe individual schemes supported
+ by the service.
+
+3.2.18.1. <s> Element
+
+ The <s> element is of string type and is used to describe an
+ individual scheme supported by the service. Values that can be used
+ here are scheme names that are registered to the IANA URI scheme
+ registry.
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 11]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+3.2.19. <actor> Element
+
+ The <actor> element indicates the type of entity that is available at
+ this URI as defined in [RFC3840].
+
+ The <actor> element can contain two elements: <supported> and
+ <notsupported>. Actor types that are supported by the service can be
+ listed under the <supported> element, and actor types that are not
+ supported by the service can be listed under the <notsupported>
+ element.
+
+ The <supported> and <notsupported> elements can contain <principal>,
+ <attendant>, <msg-taker>, and <information> elements followed by any
+ number of optional extension elements from other namespaces.
+
+ The semantics of these elements are defined in [RFC3840] as:
+
+ o <principal>: The service provides communication with the principal
+ that is associated with the service. Often this will be a
+ specific human being, but it can be an automaton (for example,
+ when calling a voice portal).
+
+ o <attendant>: The service provides communication with an automaton
+ or a person that will act as an intermediary in contacting the
+ principal associated with the service, or a substitute.
+
+ o <msg-taker>: The service provides communication with an automaton
+ or a person that will take messages and deliver them to the
+ principal.
+
+ o <information>: The service provides communication with an
+ automaton or a person that will provide information about the
+ principal.
+
+ Any value that is registered with IANA for the SIP media feature tag
+ registration tree as a sip.actor media feature tag can be used as a
+ value of an extension element. If the appropriate value is not
+ registered, it SHOULD be registered as defined in [RFC3840].
+
+3.2.20. <isfocus> Element
+
+ The <isfocus> element indicates that the service is a conference
+ server, also known as a focus as defined in [RFC3840].
+
+ The <isfocus> element is of boolean type and does not have any
+ attributes. The value 'true' indicates that service is a conference
+ server and the value 'false' indicates that service does not support
+ conferencing.
+
+
+
+Lonnfors & Kiss Standards Track [Page 12]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+3.2.21. <languages> Element
+
+ The <languages> element indicates the ability to display particular
+ human languages as defined in [RFC4646].
+
+ The <languages> element can contain two elements: <supported> and
+ <notsupported>. Languages that are supported by the service can be
+ listed under the <supported> element, and languages that are not
+ supported by the service can be listed under the <notsupported>
+ element.
+
+ <supported> and <notsupported> elements can contain any number of <l>
+ elements which can be used to describe individual languages supported
+ by the service.
+
+3.2.21.1. <l> Element
+
+ The <l> element is of string type and is used to describe an
+ individual language supported by the service. Values that can be
+ used here are language subtags that are registered to the IANA
+ language subtag registry as per [RFC4646].
+
+3.3. Device Capabilities
+
+ Elements belonging to device capabilities are used to describe
+ dynamic characteristics of a device. These capabilities are enclosed
+ within the <devcaps> element, which SHOULD be located in the PIDF
+ document as a child element of the
+ urn:ietf:params:xml:ns:pidf:data-model namespace <device> element
+ [RFC4479].
+
+ The namespace identifier for these elements is urn:
+
+ ietf:params:xml:ns:pidf:caps
+
+3.3.1. <devcaps> Element
+
+ The root element of device capabilities is <devcaps>. The root
+ element always has to be present. This element can contain the
+ following child elements: <mobility> and <description> followed by
+ any number of optional extension elements from other namespaces.
+
+ A <devcaps> element can contain any number of optional extension
+ attributes from other namespaces.
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 13]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+3.3.2. <mobility> Element
+
+ The <mobility> element indicates whether the device is fixed (meaning
+ that it is associated with a fixed point of contact with the network)
+ or mobile (meaning that it is not associated with a fixed point of
+ contact). Note that cordless phones are fixed, not mobile, based on
+ this definition as defined in [RFC3840].
+
+ The <mobility> element can contain two elements: <supported> and
+ <notsupported>. Mobility modes that are supported by the device can
+ be listed under the <supported> element and mobility modes that are
+ not supported by the device can be listed under the <notsupported>
+ element.
+
+ The <supported> and <notsupported> elements can contain <fixed> and
+ <mobile> elements followed by any number of optional extension
+ elements from other namespaces.
+
+ The semantics of these elements are defined in [RFC3840] as:
+
+ o <fixed>: The device is stationary.
+
+ o <mobile>: The device can move around with the user.
+
+ Any value that is registered with IANA to the SIP media feature tag
+ registration tree as sip.mobility media feature tag can be used as a
+ value of an extension element. If the appropriate value is not
+ registered, it SHOULD be registered as defined in [RFC3840].
+
+3.3.3. <description> Element
+
+ The <description> element provides a textual description of the
+ device as defined in [RFC3840].
+
+ The <description> element is of string type and does not have any
+ attributes.
+
+ The <description> element SHOULD be labeled with the 'xml:lang'
+ attribute to indicate its language and script. The specification
+ allows multiple occurrences of this element so that the presentity
+ can convey <description> elements in multiple scripts and languages.
+ If no 'xml:lang' attribute is provided, the default value is
+ "i-default" as defined in [RFC2277].
+
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 14]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+4. Usage Guidelines
+
+ The User Agent Capabilities extension [RFC3840] recommends that a UA
+ provides complete information in its contact predicate. However, it
+ may be that the presentity is not willing to publish presence
+ information that would be consistent with actual device or service
+ capabilities (e.g., presentity may not want to indicate that he/she
+ supports voice when the service actually is able to support it).
+ Authorization rules or policies in the presence server may limit or
+ modify the presence information published by the presentity. Also,
+ combining presence information from multiple sources may result in
+ loss or mismatch of information.
+
+ It is RECOMMENDED that Presence User Agents (PUAs) using this
+ extension provide as complete presence information as they can. If
+ the PUA is publishing sensitive information using this extension, it
+ SHOULD obtain permission from the presentity. PUAs can indicate the
+ explicitly supported capabilities using the <supported> element, and
+ the capabilities that are explicitly not supported using the
+ <notsupported> element.
+
+ It is not mandated that presence information be consistent with
+ actual service or device capabilities. However, it is in the
+ presentity's best interest to avoid publishing false presence
+ information and provide accurate information to help minimize
+ unsuccessful communication invitations. Otherwise, watchers may
+ conclude that communication cannot be established with the
+ presentity, but in reality it would be possible; or watchers may
+ conclude that certain communication capabilities are available, but
+ in reality a communication establishment attempt would fail using
+ those capabilities. In any case, watchers should not expect the
+ presence information represented by this extension to be fully
+ aligned with the actual presentity's service or device capabilities.
+ As explained in Section 1.2, presence of this extension does not
+ replace the use of SIP signaling for capability negotiation.
+
+4.1. Use of <supported> and <notsupported> Elements
+
+ PUAs should add information under <supported> and <notsupported>
+ elements only when they believe it may affect the decision making in
+ the watcher's end, i.e., information should be relevant and valuable
+ for the watcher. Listing all possible information under <supported>
+ and <notsupported> is rarely needed.
+
+ For example, if the PUA wants to advertise a message service that
+ supports the MESSAGE method, it should add it under the <supported>
+ element in the <methods> element. Even if the service does not
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 15]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ support other methods, it is unlikely that listing all the methods
+ not supported under the <notsupported> element would provide any
+ value to the watcher.
+
+ In case of conflicting information, i.e., the same child element
+ appears under the <supported> and <notsupported> elements with the
+ same value, the watcher can safely assume that the listed capability
+ is supported regardless of the inclusion of the capability under the
+ <notsupported> element.
+
+5. Examples
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
+ xmlns:mod="urn:ietf:params:xml:ns:pidf:data-model"
+ entity="pres:someone@example.com">
+
+ <tuple id="joi9877866786ua9">
+ <status>
+ <basic>open</basic>
+ </status>
+ <caps:servcaps>
+ <caps:audio>true</caps:audio>
+ <caps:description xml:lang="en">
+ Example service
+ </caps:description>
+ <caps:description xml:lang="hu">
+ Pe'lda szolga'ltata's
+ </caps:description>
+ <caps:duplex>
+ <caps:supported>
+ <caps:full/>
+ </caps:supported>
+ </caps:duplex>
+ <caps:message>true</caps:message>
+ <caps:methods>
+ <caps:supported>
+ <caps:ACK/>
+ <caps:BYE/>
+ <caps:INVITE/>
+ <caps:MESSAGE/>
+ </caps:supported>
+ </caps:methods>
+ <caps:priority>
+ <caps:supported>
+ <caps:lowerthan maxvalue="10"/>
+ </caps:supported>
+
+
+
+Lonnfors & Kiss Standards Track [Page 16]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ </caps:priority>
+ <caps:schemes>
+ <caps:supported>
+ <caps:s>sip</caps:s>
+ </caps:supported>
+ </caps:schemes>
+ <caps:video>false</caps:video>
+ </caps:servcaps>
+ <contact>sip:someone@example.com</contact>
+ </tuple>
+ <mod:device id="hgt67">
+ <caps:devcaps>
+ <caps:mobility>
+ <caps:supported>
+ <caps:mobile/>
+ </caps:supported>
+ </caps:mobility>
+ </caps:devcaps>
+ <mod:deviceID
+ >urn:uuid:d27459b7-8213-4395-aa77-ed859a3e5b3a</mod:deviceID>
+ </mod:device>
+ </presence>
+
+6. XML Schema Definitions
+
+ This section gives the XML schema definitions for the extensions
+ defined in this document. The namespace identifier for this schema
+ is urn:ietf:params:xml:ns:pidf:caps.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<xs:schema xmlns:tns="urn:ietf:params:xml:ns:pidf:caps"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ targetNamespace="urn:ietf:params:xml:ns:pidf:caps"
+ elementFormDefault="qualified"
+ attributeFormDefault="unqualified">
+
+<!-- This import brings in the XML language
+ attribute xml:lang-->
+
+ <xs:import namespace="http://www.w3.org/XML/1998/namespace"
+ schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+
+<!-- ROOT -->
+ <xs:element name="servcaps" type="tns:servcapstype"/>
+ <xs:complexType name="servcapstype">
+ <xs:sequence>
+ <xs:element name="actor" type="tns:actortype"
+ minOccurs="0"/>
+
+
+
+Lonnfors & Kiss Standards Track [Page 17]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ <xs:element name="application" type="tns:applicationtype"
+ minOccurs="0"/>
+ <xs:element name="audio" type="tns:audiotype" minOccurs="0"/>
+ <xs:element name="automata" type="tns:automatatype"
+ minOccurs="0"/>
+ <xs:element name="class" type="tns:classtype"
+ minOccurs="0"/>
+ <xs:element name="control" type="tns:controltype"
+ minOccurs="0"/>
+ <xs:element name="data" type="tns:datatype"
+ minOccurs="0"/>
+ <xs:element name="description" type="tns:descriptiontype"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <xs:element name="duplex" type="tns:duplextype"
+ minOccurs="0"/>
+ <xs:element name="event-packages" type="tns:event-packagestype"
+ minOccurs="0"/>
+ <xs:element name="extensions" type="tns:extensionstype"
+ minOccurs="0"/>
+ <xs:element name="isfocus" type="tns:isfocustype"
+ minOccurs="0"/>
+ <xs:element name="message" type="tns:messagetype"
+ minOccurs="0"/>
+ <xs:element name="methods" type="tns:methodstype"
+ minOccurs="0"/>
+ <xs:element name="languages" type="tns:languagestype"
+ minOccurs="0"/>
+ <xs:element name="priority" type="tns:prioritytype"
+ minOccurs="0"/>
+ <xs:element name="schemes" type="tns:schemestype"
+ minOccurs="0"/>
+ <xs:element name="text" type="tns:texttype"
+ minOccurs="0"/>
+ <xs:element name="type" type="tns:typetype"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <xs:element name="video" type="tns:videotype"
+ minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+ <xs:element name="devcaps" type="tns:devcaps"/>
+ <xs:complexType name="devcaps">
+ <xs:sequence>
+ <xs:element name="description" type="tns:descriptiontype"
+ minOccurs="0" maxOccurs="unbounded"/>
+
+
+
+Lonnfors & Kiss Standards Track [Page 18]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ <xs:element name="mobility" type="tns:mobilitytype"
+ minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ <xs:anyAttribute namespace="##any" processContents="lax"/>
+ </xs:complexType>
+
+ <!-- AUDIO -->
+ <xs:simpleType name="audiotype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- APPLICATION -->
+ <xs:simpleType name="applicationtype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- DATA -->
+ <xs:simpleType name="datatype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- CONTROL -->
+ <xs:simpleType name="controltype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- VIDEO -->
+ <xs:simpleType name="videotype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- TEXT -->
+ <xs:simpleType name="texttype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- MESSAGE -->
+ <xs:simpleType name="messagetype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- TYPE -->
+ <xs:simpleType name="typetype">
+ <xs:restriction base="xs:string"/>
+ </xs:simpleType>
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 19]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ <!-- AUTOMATA -->
+ <xs:simpleType name="automatatype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- CLASS -->
+ <xs:complexType name="classtype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:classtypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:classtypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="classtypes">
+ <xs:sequence>
+ <xs:element name="business" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="personal" type="xs:string"
+ minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0"
+ maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- DUPLEX -->
+ <xs:complexType name="duplextype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:duplextypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:duplextypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="duplextypes">
+ <xs:sequence>
+ <xs:element name="full" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="half" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="receive-only" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="send-only" type="xs:string"
+ minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+
+
+
+Lonnfors & Kiss Standards Track [Page 20]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ </xs:complexType>
+
+ <!-- DESCRIPTION -->
+ <xs:complexType name="descriptiontype">
+ <xs:simpleContent>
+ <xs:extension base="xs:string">
+ <xs:attribute ref="xml:lang"/>
+ </xs:extension>
+ </xs:simpleContent>
+ </xs:complexType>
+
+ <!-- EVENT-PACKAGES -->
+ <xs:complexType name="event-packagestype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:eventtypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:eventtypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="eventtypes">
+ <xs:sequence>
+ <xs:element name="conference" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="dialog" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="kpml" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="message-summary" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="poc-settings" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="presence" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="reg" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="refer" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="Siemens-RTP-Stats"
+ type="xs:string" minOccurs="0"/>
+ <xs:element name="spirits-INDPs"
+ type="xs:string" minOccurs="0"/>
+ <xs:element name="spirits-user-prof"
+ type="xs:string" minOccurs="0"/>
+ <xs:element name="winfo" type="xs:string"
+ minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+
+
+
+Lonnfors & Kiss Standards Track [Page 21]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- PRIORITY -->
+ <xs:complexType name="prioritytype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:prioritytypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:prioritytypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="prioritytypes">
+ <xs:sequence>
+ <xs:element name="equals" type="tns:equalstype"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <xs:element name="higherhan" type="tns:higherthantype"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <xs:element name="lowerthan" type="tns:lowerthantype"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <xs:element name="range" type="tns:rangetype"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="lowerthantype">
+ <xs:attribute name="maxvalue" type="xs:integer"
+ use="required"/>
+ </xs:complexType>
+ <xs:complexType name="higherthantype">
+ <xs:attribute name="minvalue" type="xs:integer"
+ use="required"/>
+ </xs:complexType>
+ <xs:complexType name="equalstype">
+ <xs:attribute name="value" type="xs:integer"
+ use="required"/>
+ </xs:complexType>
+ <xs:complexType name="rangetype">
+ <xs:attribute name="minvalue" type="xs:integer"
+ use="required"/>
+ <xs:attribute name="maxvalue" type="xs:integer"
+ use="required"/>
+ </xs:complexType>
+
+ <!-- METHODS -->
+ <xs:complexType name="methodstype">
+ <xs:sequence>
+
+
+
+Lonnfors & Kiss Standards Track [Page 22]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ <xs:element name="supported" type="tns:methodtypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:methodtypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="methodtypes">
+ <xs:sequence>
+ <xs:element name="ACK" type="xs:string" minOccurs="0"/>
+ <xs:element name="BYE" type="xs:string" minOccurs="0"/>
+ <xs:element name="CANCEL" type="xs:string" minOccurs="0"/>
+ <xs:element name="INFO" type="xs:string" minOccurs="0"/>
+ <xs:element name="INVITE" type="xs:string" minOccurs="0"/>
+ <xs:element name="MESSAGE" type="xs:string" minOccurs="0"/>
+ <xs:element name="NOTIFY" type="xs:string" minOccurs="0"/>
+ <xs:element name="OPTIONS" type="xs:string" minOccurs="0"/>
+ <xs:element name="PRACK" type="xs:string" minOccurs="0"/>
+ <xs:element name="PUBLISH" type="xs:string" minOccurs="0"/>
+ <xs:element name="REFER" type="xs:string" minOccurs="0"/>
+ <xs:element name="REGISTER" type="xs:string" minOccurs="0"/>
+ <xs:element name="SUBSCRIBE" type="xs:string" minOccurs="0"/>
+ <xs:element name="UPDATE" type="xs:string" minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- EXTENSIONS -->
+ <xs:complexType name="extensionstype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:extensiontypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:extensiontypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="extensiontypes">
+ <xs:sequence>
+ <xs:element name="rel100" type="xs:string" minOccurs="0"/>
+ <xs:element name="early-session" type="xs:string" minOccurs="0"/>
+ <xs:element name="eventlist" type="xs:string" minOccurs="0"/>
+ <xs:element name="from-change" type="xs:string" minOccurs="0"/>
+ <xs:element name="gruu" type="xs:string" minOccurs="0"/>
+ <xs:element name="hist-info" type="xs:string" minOccurs="0"/>
+ <xs:element name="join" type="xs:string" minOccurs="0"/>
+ <xs:element name="norefersub" type="xs:string" minOccurs="0"/>
+ <xs:element name="path" type="xs:string" minOccurs="0"/>
+ <xs:element name="precondition" type="xs:string" minOccurs="0"/>
+
+
+
+Lonnfors & Kiss Standards Track [Page 23]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ <xs:element name="pref" type="xs:string" minOccurs="0"/>
+ <xs:element name="privacy" type="xs:string" minOccurs="0"/>
+ <xs:element name="recipient-list-invite" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="recipient-list-subscribe" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="replaces" type="xs:string" minOccurs="0"/>
+ <xs:element name="resource-priority" type="xs:string" minOccurs="0"/>
+ <xs:element name="sdp-anat" type="xs:string" minOccurs="0"/>
+ <xs:element name="sec-agree" type="xs:string" minOccurs="0"/>
+ <xs:element name="tdialog" type="xs:string" minOccurs="0"/>
+ <xs:element name="timer" type="xs:string" minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- SCHEMES -->
+ <xs:complexType name="schemestype">
+ <xs:sequence>
+ <xs:element name="supported" minOccurs="0">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="s" type="xs:string" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ <xs:element name="notsupported" minOccurs="0">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="s" type="xs:string" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- ACTOR -->
+ <xs:complexType name="actortype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:actortypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:actortypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="actortypes">
+ <xs:sequence>
+
+
+
+Lonnfors & Kiss Standards Track [Page 24]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ <xs:element name="attendant" type="xs:string" minOccurs="0"/>
+ <xs:element name="information" type="xs:string" minOccurs="0"/>
+ <xs:element name="msg-taker" type="xs:string" minOccurs="0"/>
+ <xs:element name="principal" type="xs:string" minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- ISFOCUS -->
+ <xs:simpleType name="isfocustype">
+ <xs:restriction base="xs:boolean"/>
+ </xs:simpleType>
+
+ <!-- LANGUAGES -->
+ <xs:complexType name="languagestype">
+ <xs:sequence>
+ <xs:element name="supported" minOccurs="0">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="l" type="xs:string" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ <xs:element name="notsupported" minOccurs="0">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="l" type="xs:string" maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+
+ <!-- MOBILITY -->
+ <xs:complexType name="mobilitytype">
+ <xs:sequence>
+ <xs:element name="supported" type="tns:mobilitytypes"
+ minOccurs="0"/>
+ <xs:element name="notsupported" type="tns:mobilitytypes"
+ minOccurs="0"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="mobilitytypes">
+ <xs:sequence>
+ <xs:element name="fixed" type="xs:string"
+ minOccurs="0"/>
+ <xs:element name="mobile" type="xs:string"
+
+
+
+Lonnfors & Kiss Standards Track [Page 25]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ minOccurs="0"/>
+ <xs:any namespace="##other" processContents="lax" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </xs:sequence>
+ </xs:complexType>
+</xs:schema>
+
+7. IANA Considerations
+
+ IANA has registered one new XML namespace URN and one schema as
+ defined in [RFC3688].
+
+7.1. URN Sub-Namespace Registration for
+ 'urn:ietf:params:xml:ns:pidf:caps'
+
+ URI:
+ urn:ietf:params:xml:ns:pidf:caps
+
+ Description:
+ This is the XML namespace for XML elements defined by RFC 5196 to
+ describe service and device capabilities in application/pidf+xml
+ content type.
+
+ Registrant Contact:
+ IETF, SIMPLE working group, <simple@ietf.org>
+ Mikko Lonnfors, <mikko.lonnfors@nokia.com>
+
+ XML:
+
+ BEGIN
+ <?xml version="1.0"?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
+ "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
+ <html> xmlns="http://www.w3.org/1999/xhtml"
+ <head>
+ <meta http-equiv="content-type"
+ content="text/html;charset=iso-8859-1"/>
+ <title>Namespace for PIDF user agent capability
+ extension</title>
+ </head>
+ <body>
+ <h1>Namespace for PIDF service capability extension</h1>
+ <h2>urn:ietf:params:xml:ns:pidf:caps</h2>
+ <p>
+ See <a href="http://www.rfc-editor.org/rfc/rfc5196.txt">RFC
+ 5196</a>.
+ </p>
+ </body>
+
+
+
+Lonnfors & Kiss Standards Track [Page 26]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ </html>
+ END
+
+7.2. Schema Registration for Schema
+ 'urn:ietf:params:xml:schema:pidf:caps'
+
+ URI:
+ urn:ietf:params:xml:schema:pidf:caps
+
+ Registrant Contact:
+ IESG
+
+ XML:
+ See Section 6
+
+8. Security Considerations
+
+ All security considerations specified in [RFC3859] and [RFC3863]
+ apply to this document. Compared to PIDF [RFC3863], this presence
+ document format may reveal additional information about user's
+ service and device capabilities. Thus, the PUA SHOULD always obtain
+ permission from the presentity when publishing sensitive information
+ using this extension.
+
+9. Acknowledgments
+
+ Authors of this document would like to thank the following people for
+ their contributions and valuable comments: Paul Kyzivat, Jonathan
+ Rosenberg, Markus Isomaki, Eva Leppanen, Miguel Garcia, Jari
+ Urpalainen, and Hisham Khartabil.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) part one: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998.
+
+ [RFC2913] Klyne, G., "MIME Content Types in Media Feature
+ Expressions", RFC 2913, September 2000.
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 27]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ January 2004.
+
+ [RFC3840] Schulzrinne, H., Rosenberg, J., and P. Kyzivat,
+ "Indicating User Agent Capabilities in the Session
+ Initiation Protocol (SIP)", RFC 3840, August 2004.
+
+ [RFC3859] Peterson, J., "Common Profile for Presence (CPP)",
+ RFC 3859, August 2004.
+
+ [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
+ W., and J. Peterson, "Presence Information Data Format
+ (PIDF)", RFC 3863, August 2004.
+
+ [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
+ July 2006.
+
+ [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
+ Languages", BCP 47, RFC 4646, September 2006.
+
+10.2. Informative References
+
+ [RFC2648] Moats, R., "A URN namespace for IETF documents", RFC 2648,
+ August 1999.
+
+ [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
+ Presence and Instant Messaging", RFC 2778, February 2000.
+
+ [RFC3860] Peterson, J., "Common Profile for Instant Messaging
+ (CPIM)", RFC 3860, August 2004.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC4569] Camarillo, G., "Internet Assigned Numbers Authority (IANA)
+ Registration of the Message Media Feature Tag", RFC 4569,
+ July 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 28]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+Authors' Addresses
+
+ Mikko Lonnfors
+ Nokia
+ P.O. Box 321
+ Helsinki
+ Finland
+
+ Phone: +358 71 8008000
+ EMail: mikko.lonnfors@nokia.com
+
+
+ Krisztian Kiss
+ Nokia
+ 313 Fairchild Dr
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 650 391 5969
+ EMail: krisztian.kiss@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 29]
+
+RFC 5196 User Agent Capability Presence Status September 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Lonnfors & Kiss Standards Track [Page 30]
+