idnits 2.17.1 

draft-ietf-simple-prescaps-ext-10.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 16.

  -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
     line 1327.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1338.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1345.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1351.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
     current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (May 14, 2008) is 5819 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)

  -- Obsolete informational reference (is this intentional?): RFC 4566
     (Obsoleted by RFC 8866)


     Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	SIMPLE WG                                                    M. Lonnfors
3	Internet-Draft                                                   K. Kiss
4	Intended status: Standards Track                                   Nokia
5	Expires: November 15, 2008                                  May 14, 2008

7	  Session Initiation Protocol (SIP) User Agent Capability Extension to
8	                Presence Information Data Format (PIDF)
9	                   draft-ietf-simple-prescaps-ext-10

11	Status of this Memo

13	   By submitting this Internet-Draft, each author represents that any
14	   applicable patent or other IPR claims of which he or she is aware
15	   have been or will be disclosed, and any of which he or she becomes
16	   aware will be disclosed, in accordance with Section 6 of BCP 79.

18	   Internet-Drafts are working documents of the Internet Engineering
19	   Task Force (IETF), its areas, and its working groups.  Note that
20	   other groups may also distribute working documents as Internet-
21	   Drafts.

23	   Internet-Drafts are draft documents valid for a maximum of six months
24	   and may be updated, replaced, or obsoleted by other documents at any
25	   time.  It is inappropriate to use Internet-Drafts as reference
26	   material or to cite them other than as "work in progress."

28	   The list of current Internet-Drafts can be accessed at
29	   http://www.ietf.org/ietf/1id-abstracts.txt.

31	   The list of Internet-Draft Shadow Directories can be accessed at
32	   http://www.ietf.org/shadow.html.

34	   This Internet-Draft will expire on November 15, 2008.

36	Abstract

38	   Presence Information Data Format (PIDF) defines a common presence
39	   data format for Common Profile for Presence (CPP) compliant Presence
40	   protocols.  This memo defines an extension to represent SIP User
41	   Agent capabilities in the Presence Information Document Format (PIDF)
42	   compliant presence documents.

44	Table of Contents

46	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
47	     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
48	     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
49	   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
50	   3.  Extension for "Indicating User Agent Capabilities in the
51	       Session Initiation Protocol (SIP)" in PIDF documents . . . . .  5
52	     3.1.  Overview of operation  . . . . . . . . . . . . . . . . . .  5
53	     3.2.  Service capabilities . . . . . . . . . . . . . . . . . . .  6
54	       3.2.1.  <servcaps> element . . . . . . . . . . . . . . . . . .  6
55	       3.2.2.  <audio> element  . . . . . . . . . . . . . . . . . . .  6
56	       3.2.3.  <application> element  . . . . . . . . . . . . . . . .  6
57	       3.2.4.  <data> element . . . . . . . . . . . . . . . . . . . .  7
58	       3.2.5.  <control> element  . . . . . . . . . . . . . . . . . .  7
59	       3.2.6.  <video> element  . . . . . . . . . . . . . . . . . . .  7
60	       3.2.7.  <text> element . . . . . . . . . . . . . . . . . . . .  7
61	       3.2.8.  <message> element  . . . . . . . . . . . . . . . . . .  8
62	       3.2.9.  <type> element . . . . . . . . . . . . . . . . . . . .  8
63	       3.2.10. <automata> element . . . . . . . . . . . . . . . . . .  8
64	       3.2.11. <class> element  . . . . . . . . . . . . . . . . . . .  8
65	       3.2.12. <duplex> element . . . . . . . . . . . . . . . . . . .  9
66	       3.2.13. <description> element  . . . . . . . . . . . . . . . .  9
67	       3.2.14. <event-packages> element . . . . . . . . . . . . . . . 10
68	       3.2.15. <priority> element . . . . . . . . . . . . . . . . . . 10
69	       3.2.16. <methods> element  . . . . . . . . . . . . . . . . . . 11
70	       3.2.17. <extensions> element . . . . . . . . . . . . . . . . . 11
71	       3.2.18. <schemes> element  . . . . . . . . . . . . . . . . . . 12
72	       3.2.19. <actor> element  . . . . . . . . . . . . . . . . . . . 12
73	       3.2.20. <isfocus> element  . . . . . . . . . . . . . . . . . . 13
74	       3.2.21. <languages> element  . . . . . . . . . . . . . . . . . 13
75	     3.3.  Device capabilities  . . . . . . . . . . . . . . . . . . . 14
76	       3.3.1.  <devcaps> element  . . . . . . . . . . . . . . . . . . 14
77	       3.3.2.  <mobility> element . . . . . . . . . . . . . . . . . . 14
78	       3.3.3.  <description> element  . . . . . . . . . . . . . . . . 15
79	   4.  Usage guidelines . . . . . . . . . . . . . . . . . . . . . . . 15
80	     4.1.  Use of <supported> and <notsupported> elements . . . . . . 16
81	   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
82	   6.  XML schema definitions . . . . . . . . . . . . . . . . . . . . 18
83	   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
84	     7.1.  URN sub-namespace registration for
85	           'urn:ietf:params:xml:ns:pidf:caps' . . . . . . . . . . . . 26
86	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
87	   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
88	   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
89	     10.1. Normative references . . . . . . . . . . . . . . . . . . . 28
90	     10.2. Informative references . . . . . . . . . . . . . . . . . . 28
91	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
92	   Intellectual Property and Copyright Statements . . . . . . . . . . 30

94	1.  Introduction

96	   Common Profile for Presence (CPP) [RFC3859] and Common Profile for
97	   Instant Messaging (CPIM) [RFC3860] define common operations and
98	   formats which all presence and instant messaging services must agree
99	   upon so that basic interoperability would be possible.  The actual
100	   base format for the presence is defined in the Presence Information
101	   Document Format (PIDF) [RFC3863].  The PIDF has been designed to
102	   reduce the need for gatewaying and to allow end-to-end security of
103	   presence data.  It has taken a very minimalistic approach to support
104	   such operations.  In order to make the PIDF usable by different
105	   presence applications, these applications usually must extend the
106	   basic PIDF by standard XML mechanisms as defined in PIDF [RFC3863].

108	   The aim of this memo is to introduce a SIP specific extension
109	   mechanism to the PIDF that conveys the same SIP media feature tags as
110	   described in [RFC3840].  With this extension presence applications
111	   based on SIP can have richer and more usable presence data compared
112	   to the baseline PIDF.

114	1.1.  Motivation

116	   The PIDF [RFC3863] defines a <contact> element which may appear once
117	   inside every <tuple> element.  The content of the <contact> element
118	   encodes the CONTACT ADDRESS and CONTACT MEANS as defined in
119	   [RFC2778].  The <contact> element is defined to be a URI of any
120	   scheme.  In some implementations the URI scheme can uniquely identify
121	   the service the tuple intends to describe (e.g. im: URI scheme
122	   usually represents Instant Messaging service).  However, this may not
123	   be the case in all implementations.  For example in SIP, a SIP URI
124	   scheme can represent different kinds of services.  A SIP URI scheme
125	   can be used to contact voice services, video services, or messaging
126	   services.  If it is not known by other means, it might be hard for
127	   applications processing the presence information document containing
128	   only a SIP URI contact addresses to know what particular service the
129	   tuple intends to describe.  Also watchers receiving presence
130	   information would probably benefit for getting more descriptive
131	   information about what particular communication means or services are
132	   supported by the presentity.

134	   The User Agent Capabilities extension [RFC3840] defines a set of
135	   extensions which allow user agents to express preferences about
136	   request handling in SIP servers.  The same information can provide
137	   value also to presence watchers so that they can make more rational
138	   decisions on how a presentity should be contacted if a presence
139	   document contained similar information.

141	1.2.  Scope

143	   This document defines PIDF extensions which enable SIP presence
144	   implementations to utilize User Agent Capabilities [RFC3840] within
145	   presence documents.

147	   This extension does not replace media negotiation mechanisms defined
148	   for SIP (e.g.  SDP [RFC4566]).  This extension is only aimed for
149	   presentities to give watchers hints about the presentity's
150	   preferences, willingness and capabilities to communicate before
151	   watchers initiate a communication with the presentity.

153	2.  Conventions

155	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
156	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
157	   document are to be interpreted as described in [RFC2119].

159	   This memo makes use of the vocabulary defined in [RFC2778], and in
160	   [RFC3863].

162	3.  Extension for "Indicating User Agent Capabilities in the Session
163	    Initiation Protocol (SIP)" in PIDF documents

165	   This section presents all extension documents, their elements, their
166	   values, and semantics.  This section also describes how this
167	   extension can be further extended.

169	   This extension is intended to be used within a PIDF [RFC3863] and
170	   that particular usage is described here.  This extension may also be
171	   used with other XML documents if appropriate.

173	3.1.  Overview of operation

175	   This document defines how the features presented in [RFC3840] can be
176	   provided as a part of presence data.  Additionally, this memo
177	   includes the "type" feature tag [RFC2913], "message" media type
178	   feature tag [RFC4569] and the "language" feature tag [RFC4646]
179	   definitions.  Bringing these features in the PIDF means mapping them
180	   to an XML formatted structure.

182	   The presence data model [RFC4479] defines presence data consisting of
183	   three types of data elements: person, service, and device.  This memo
184	   follows this model so that one XML document is defined to describe
185	   device capabilities and another one to describe service capabilities.

187	   The namespace URIs for elements defined by this document are URNs
188	   using the namespace identifier 'ietf' defined by [RFC2648] and
189	   extended by [RFC3688].

191	   When these extension namespaces are congregated with the PIDF
192	   document, the combined document MUST follow the same general
193	   formatting rules as specified in Section 4.1 of [RFC3863].

195	3.2.  Service capabilities

197	   Elements belonging to service capabilities are used to describe
198	   dynamic characteristics of a service.  These capabilities are
199	   enclosed within the <servcaps> element which SHOULD be located in
200	   PIDF document as a child element of urn:ietf:params:xml:ns:pidf
201	   namespace <tuple> [RFC3863] element.

203	   Namespace identifier for these elements is:

205	   urn:ietf:params:xml:ns:pidf:caps

207	3.2.1.  <servcaps> element

209	   The root element of service capabilities is <servcaps>.  The root
210	   element has to be always present.  This element can contain following
211	   elements: <audio>, <application>, <control>, <video>, <text>,
212	   <message>, <type>, <automata>, <class>, <duplex>, <description>,
213	   <event-packages>, <priority>, <methods>, <extensions>, <schemes>,
214	   <actor>, <isfocus>, and <languages> followed by any number of
215	   optional extension elements from other namespaces.

217	   A <servcaps> element can contain any number of optional extension
218	   attributes from other namespaces.

220	3.2.2.  <audio> element

222	   The <audio> element indicates that the service supports audio as a
223	   streaming media type as defined in [RFC3840].

225	   The <audio> element is a boolean type and does not have any
226	   attributes.  The value 'true' indicates that service supports audio
227	   media type and the value 'false' indicates that service does not
228	   support audio media type.

230	3.2.3.  <application> element

232	   The <application> element indicates that the service supports
233	   application as a streaming media type as defined in [RFC3840].

235	   The <application> element is a boolean type and does not have any
236	   attributes.  The value 'true' indicates that service supports
237	   application media type and the value 'false' indicates that service
238	   does not support application media type.

240	3.2.4.  <data> element

242	   The <data> element indicates that the service supports data as a
243	   streaming media type as defined in [RFC3840].

245	   The <data> element is a boolean type and does not have any
246	   attributes.  The value 'true' indicates that service supports data
247	   media type and the value 'false' indicates that service does not
248	   support data media type.

250	3.2.5.  <control> element

252	   The <control> element indicates that the service supports control as
253	   a streaming media type as defined in [RFC3840].

255	   The <control> element is a boolean type and does not have any
256	   attributes.  The value 'true' indicates that service supports control
257	   media type and the value 'false' indicates that service does not
258	   support control media type.

260	3.2.6.  <video> element

262	   The <video> element indicates that the service supports video as a
263	   streaming media type as defined in [RFC3840].

265	   The <video> element is a boolean type and does not have any
266	   attributes.  The value 'true' indicates that service supports video
267	   media type and the value 'false' indicates that service does not
268	   support video media type.

270	3.2.7.  <text> element

272	   The <text> element indicates that the service supports text as a
273	   streaming media type as defined in [RFC3840].

275	   The <text> element is a boolean type and does not have any
276	   attributes. the value 'true' indicates that service supports text
277	   media type and the value 'false' indicates that service does not
278	   support text media type.

280	3.2.8.  <message> element

282	   The <message> element indicates that the service supports messaging
283	   as a streaming media type as defined in [RFC4569].

285	   The <message> element is a boolean type and does not have any
286	   attributes.  The value 'true' indicates that service supports message
287	   media type and the value 'false' indicates that service does not
288	   support message media type.

290	3.2.9.  <type> element

292	   The <type> element indicates a MIME media content type (i.e. that
293	   appears in a 'Content-type:' header of the corresponding MIME-
294	   formatted data) as defined in [RFC2913].

296	   The <type> element is a string type and does not have any attributes.
297	   It MUST be a string of the form "type/subtype", where 'type' and
298	   'subtype' are defined by the MIME specification [RFC2045].  Only
299	   lower-case letters SHOULD be used.

301	3.2.10.  <automata> element

303	   The <automata> element indicates whether the service represents an
304	   automaton (such as a voicemail server, conference server, or
305	   recording device) or a human as defined in [RFC3840].

307	   The <automata> element is a boolean type and does not have any
308	   attributes.  The value 'true' indicates that the service represents
309	   an automaton and the value 'false' indicates that it represents a
310	   human.

312	3.2.11.  <class> element

314	   The <class> element indicates the setting, business or personal, in
315	   which a communications service is used as defined in [RFC3840].

317	   The <class> element can contain two elements: <supported> and
318	   <notsupported>.  Classes that are supported by the service can be
319	   listed under <supported> element and classes that are not supported
320	   by the service can be listed under <notsupported> element.

322	   <supported> and <notsupported> elements can contain <business> and
323	   <personal> elements followed by any number of optional extension
324	   elements from other namespaces.  The semantics of business and
325	   personal are defined in [RFC3840] as:

327	   o  <business>: The service is used for business communications.

329	   o  <personal>: The service is used for personal communications.

331	   Any value that is registered with IANA for the SIP Media Feature Tag
332	   Registration Tree as a sip.class media feature tag can be used as a
333	   value of an extension element.  If the appropriate value is not
334	   registered it SHOULD be registered as defined in [RFC3840].

336	3.2.12.  <duplex> element

338	   The <duplex> element lists whether a communications service can
339	   simultaneously send and receive media ("full"), alternate between
340	   sending and receiving ("half"), only receive ("receive-only") or only
341	   send ("send-only") as defined in [RFC3840].

343	   The <duplex> element can contain two elements: <supported> and
344	   <notsupported>.  Duplex modes that are supported by the service can
345	   be listed under <supported> element and duplex modes that are not
346	   supported by the service can be listed under <notsupported> element.

348	   <supported> and <notsupported> elements can contain <full>, <half>,
349	   <receive-only> and <send-only> elements followed by any number of
350	   optional extension elements from other namespaces.  The semantics of
351	   these elements are defined in [RFC3840] as:

353	   o  <full>: The service can simultaneously send and receive media.

355	   o  <half>: The service can alternate between sending and receiving
356	      media.

358	   o  <receive-only>: The service can only receive media.

360	   o  <send-only>: The service can only send media.

362	   Any value that is registered with IANA for the SIP Media Feature Tag
363	   Registration Tree as a sip.class media feature tag can be used as a
364	   value of an extension element.  If the appropriate value is not
365	   registered it SHOULD be registered as defined in [RFC3840].

367	3.2.13.  <description> element

369	   The <description> element provides a textual description of the
370	   service as defined in [RFC3840].

372	   The <description> element is of string type and does not have any
373	   attributes.

375	   The <description> element SHOULD be labeled with the 'xml:lang'
376	   attribute to indicate its language and script.  The specification
377	   allows multiple occurrences of this elements so that the presentity
378	   can convey <description> elements in multiple scripts and languages.
379	   If no 'xml:lang' attribute is provided, the default value is
380	   "i-default" as defined in [RFC2277].

382	3.2.14.  <event-packages> element

384	   The <event-packages> element lists the event packages supported by a
385	   service.

387	   The <event-packages> element can contain two elements: <supported>
388	   and <notsupported>.  Event packages that are supported by the service
389	   can be listed under <supported> element and event packages that are
390	   not supported by the service can be listed under <notsupported>
391	   element.

393	   The <supported> and <notsupported> elements can contain any values
394	   from the IANA SIP event types namespace registry followed by any
395	   number of optional extension elements from other namespaces.  As of
396	   today the IANA SIP event types namespace registry includes the
397	   following packages: <conference>, <dialog>, <kpml>, <message-
398	   summary>, <poc-settings>, <presence>, <reg>, <refer>, <Siemens-RTP-
399	   Stats>, <spirits-INDPs>, <spirits-user-prof> and <winfo>.

401	3.2.15.  <priority> element

403	   The <priority> element indicates the call priorities the service is
404	   willing to handle as defined in [RFC3840].

406	   The <priority> element can contain two elements: <supported> and
407	   <notsupported>.  Priority values that are supported by the service
408	   can be listed under <supported> element and priority values that are
409	   not supported by the service can be listed under <notsupported>
410	   element.

412	   The <supported> and <notsupported> elements can contain any number of
413	   <lowerthan>, <higherthan>, <equals> and <range> elements followed by
414	   any number of optional extension elements from other namespaces.

416	3.2.15.1.  <lowerthan> element

418	   The <lowerthan> element has a single attribute called "maxvalue".
419	   The "maxvalue" attribute is used to give the highest priority value
420	   that the service is willing to support.  All values equal and below
421	   that value are supported.

423	3.2.15.2.  <higherthan> element

425	   The <higherthan> element has a single attribute called "minvalue".
426	   The "minvalue" attribute is used to give the lowest priority value
427	   that the service is willing to support.  All values equal and above
428	   that value are supported.

430	3.2.15.3.  <equals> element

432	   The <equals> element is used to indicate the exact priority value
433	   that the service is willing to handle.  The <equals> element has a
434	   single attribute called "value".  The "value" attribute is used to
435	   indicate the exact supported priority value.

437	3.2.15.4.  <range> element

439	   The <range> element is used to indicate the priority range that the
440	   service is willing to handle.  The <range> element has two attributes
441	   called "min" and "max".  Value of the "min" attribute indicates
442	   lowest priority value supported by the service and the value of the
443	   "max" attribute indicates the highest priority value supported by the
444	   service.

446	3.2.16.  <methods> element

448	   The <methods> element indicates the SIP methods supported by a
449	   service.  In this case, "supported" means that the service can
450	   receive requests with this method.  In that sense, it has the same
451	   connotation as the Allow header field as defined in [RFC3840].

453	   The <methods> element can contain two elements: <supported> and
454	   <notsupported>.  Methods that are supported by the service can be
455	   listed under <supported> element and methods that are not supported
456	   by the service can be listed under <notsupported> element.

458	   The <supported> and <notsupported> elements can contain <ACK>, <BYE>,
459	   <CANCEL>, <INFO>, <INVITE>, <MESSAGE>, <NOTIFY>, <OPTIONS>, <PRACK>,
460	   <PUBLISH>, <REFER>, <REGISTER>, <SUBSCRIBE>, and <UPDATE> elements
461	   followed by any number of optional extension elements from other
462	   namespaces.

464	   Any value that is registered with IANA for the SIP methods namespace
465	   registry can be used as a value of an extension element.

467	3.2.17.  <extensions> element

469	   The <extensions> element is a list of SIP extensions (each of which
470	   is defined by an option-tag registered with IANA) that are understood
471	   by the service.  Understood, in this context, means that the option
472	   tag would be included in a Supported header field in a request as
473	   defined in [RFC3840].

475	   The <extensions> element can contain two elements: <supported> and
476	   <notsupported>.  Extensions that are supported by the service can be
477	   listed under <supported> element and extensions that are not
478	   supported by the service can be listed under <notsupported> element.

480	   The <supported> and <notsupported> elements can contain any values
481	   from the IANA SIP parameters registry option tags table followed by
482	   any number of optional extension elements from other namespaces.  As
483	   of today the IANA SIP parameters registry includes the following
484	   option tags: <rel100>, <early-session>, <eventlist>, <from-change>,
485	   <gruu>, <histinfo>, <join>, <norefersub>, <path>, <precondition>,
486	   <pref>, <privacy>, <replaces>, <resource-priority>, <sdp-anat>, <sec-
487	   agree>, <tdialog> and <timer>.

489	3.2.18.  <schemes> element

491	   The <schemes> element provides the set of URI schemes that are
492	   supported by a service.  Supported implies, for example, that the
493	   service would know how to handle a URI of that scheme in the Contact
494	   header field of a redirect response as defined in [RFC3840].

496	   The <schemes> element can contain two elements: <supported> and
497	   <notsupported>.  Schemes that are supported by the service can be
498	   listed under <supported> element and schemes that are not supported
499	   by the service can be listed under <notsupported> element.

501	   <supported> and <notsupported> elements can contain any number of <s>
502	   elements which can be used to describe individual schemes supported
503	   by the service.

505	3.2.18.1.  <s> element

507	   The <s> element is of string type and it is used to describe
508	   individual scheme supported by the service.  Values that can be used
509	   here are scheme names that are registered to IANA URI scheme
510	   registry.

512	3.2.19.  <actor> element

514	   The <actor> element indicates the type of entity that is available at
515	   this URI as defined in [RFC3840].

517	   The <actor> element can contain two elements: <supported> and
518	   <notsupported>.  Actor types that are supported by the service can be
519	   listed under <supported> element and actor types that are not
520	   supported by the service can be listed under <notsupported> element.

522	   The <supported> and <notsupported> elements can contain <principal>,
523	   <attendant>, <msg-taker>, and <information> elements followed by any
524	   number of optional extension elements from other namespaces.

526	   The semantics of these elements are defined in [RFC3840] as:

528	   o  <principal>: The service provides communication with the principal
529	      that is associated with the service.  Often this will be a
530	      specific human being, but it can be an automata (for example, when
531	      calling a voice portal).

533	   o  <attendant>: The service provides communication with an automata
534	      or person that will act as an intermediary in contacting the
535	      principal associated with the service, or a substitute.

537	   o  <msg-taker>: The service provides communication with an automata
538	      or person that will take messages and deliver them to the
539	      principal.

541	   o  <information>: The service provides communication with an automata
542	      or person that will provide information about the principal.

544	   Any value that is registered with IANA for the SIP Media Feature Tag
545	   Registration Tree as a sip.class media feature tag can be used as a
546	   value of an extension element.  If the appropriate value is not
547	   registered it SHOULD be registered as defined in [RFC3840].

549	3.2.20.  <isfocus> element

551	   The <isfocus> element indicates that the service is a conference
552	   server, also known as a focus as defined in [RFC3840].

554	   The <isfocus> element is of boolean type and does not have any
555	   attributes.  The value 'true' indicates that service is a conference
556	   server and the value 'false' indicates that service does not support
557	   conferencing.

559	3.2.21.  <languages> element

561	   The <languages> element indicates the ability to display particular
562	   human languages as defined in [RFC4646].

564	   The <languages> element can contain two elements: <supported> and
565	   <notsupported>.  Languages that are supported by the service can be
566	   listed under <supported> element and languages that are not supported
567	   by the service can be listed under <notsupported> element.

569	   <supported> and <notsupported> elements can contain any number of <l>
570	   elements which can be used to describe individual languages supported
571	   by the service.

573	3.2.21.1.  <l> element

575	   The <l> element is of string type and it is used to describe
576	   individual language supported by the service.  Values that can be
577	   used here are language names that are registered to IANA as per
578	   [RFC4646].

580	3.3.  Device capabilities

582	   Elements belonging to device capabilities are used to describe
583	   dynamic characteristics of a device.  These capabilities are enclosed
584	   within the <devcaps> element which SHOULD be located in the PIDF
585	   document as a child element of urn:ietf:params:xml:ns:pidf:data-model
586	   namespace <device> element [RFC4479].

588	   Namespace identifier for these elements is urn:

590	   ietf:params:xml:ns:pidf:caps

592	3.3.1.  <devcaps> element

594	   The root element of device capabilities is <devcaps>.  The root
595	   element has to be always present.  This element can contain following
596	   elements: <mobility> and <description> followed by any number of
597	   optional extension elements from other namespaces.

599	   A <devcaps> element can contain any number of optional extension
600	   attributes from other namespaces.

602	3.3.2.  <mobility> element

604	   The <mobility> element indicates whether the device is fixed (meaning
605	   that it is associated with a fixed point of contact with the
606	   network), or mobile (meaning that it is not associated with a fixed
607	   point of contact).  Note that cordless phones are fixed, not mobile,
608	   based on this definition as defined in [RFC3840].

610	   The <mobility> element can contain two elements: <supported> and
611	   <notsupported>.  Mobility modes that are supported by the device can
612	   be listed under <supported> element and all mobility modes that are
613	   not supported by the device can be listed under <notsupported>
614	   element.

616	   The <supported> and <notsupported> elements can contain <fixed> and
617	   <mobile> elements followed by any number of optional extension
618	   elements from other namespaces.

620	   The semantics of these elements are defined in [RFC3840] as:

622	   o  <fixed>: The device is stationary.

624	   o  <mobile>: The device can move around with the user.

626	   Any value that is register to IANA to SIP Media Feature Tag
627	   Registration Tree as sip.mobility media feature tag can be used as a
628	   value of an extension element.  If the appropriate value is not
629	   registered it SHOULD be registered as defined in [RFC3840].

631	3.3.3.  <description> element

633	   The <description> element provides a textual description of the
634	   device as defined in [RFC3840].

636	   The <description> element is of string type and does not have any
637	   attributes.

639	   The <description> element SHOULD be labeled with the 'xml:lang'
640	   attribute to indicate its language and script.  The specification
641	   allows multiple occurrences of this elements so that the presentity
642	   can convey <description> elements in multiple scripts and languages.
643	   If no 'xml:lang' attribute is provided, the default value is
644	   "i-default" as defined in [RFC2277].

646	4.  Usage guidelines

648	   The User Agent Capabilities extension [RFC3840] recommends that a UA
649	   provides complete information in its contact predicate.  However, it
650	   may be that presentity is not willing to publish presence information
651	   which would be consistent with actual device or service capabilities
652	   (e.g. presentity may not want to indicate that he/she supports voice
653	   when the service actually is able to support it).  Authorization
654	   rules or policies in presence server may limit or modify the
655	   published presence information in a way that all published presence
656	   information may not end up to all possible watchers.  Also combining
657	   presence document from multiple sources may result in lose or
658	   mismatch of information.

660	   It is RECOMMENDED that Presence User Agents (PUAs) using this
661	   extension provide as complete presence information as they can.  If
662	   the PUA is publishing sensitive information using this extension, it
663	   SHOULD obtain a permission from a user.  PUAs can indicate all the
664	   explicitly supported capabilities using the <supported> element and
665	   all the explicitly not supported capabilities using the
666	   <notsupported> element, where appropriate.

668	   It is not mandated that presence information should be consistent
669	   with actual service or device capabilities.  However, it is the
670	   presentity's best interest to avoid publishing false presence
671	   information and provide accurate information to help to minimize
672	   unsuccessful communication invitations.  Otherwise, watchers may
673	   conclude that communication cannot be established with the presentity
674	   but in reality it would be possible, or certain communication
675	   capabilities are available but in reality a communication
676	   establishment attempt would fail using those capabilities.  In any
677	   case, watchers should not expect the presence information represented
678	   by this extension to be fully aligned with the actual presentity's
679	   service or device capabilities.  As explained in section Section 1.2
680	   presence of this extension does not replace the use of SIP signaling
681	   for capability negotiation.

683	4.1.  Use of <supported> and <notsupported> elements

685	   PUAs should add information under <supported> and <notsupported>
686	   elements only when they believe it may affect the decision making in
687	   the watcher's end, i.e. information should be relevant and valuable
688	   for the watcher.  Listing all possible information under <supported>
689	   and <notsupported> is rarely needed.

691	   For example, if the PUA wants to advertise a message service that
692	   supports MESSAGE method it should add it under <supported> in
693	   <methods> element.  Even if the service does not support other
694	   methods it is unlikely that listing all the not supported methods
695	   under <notsupported> would provide any value to the watcher.

697	   In case of conflicting information, i.e. same child element appears
698	   under <supported> and <notsupported> elements with same value, the
699	   watcher can safely assume that the listed capability is supported
700	   regardless of the inclusion of the capability under the
701	   <notsupported> element.

703	5.  Examples

705	   <?xml version="1.0" encoding="UTF-8"?>
706	   <presence xmlns="urn:ietf:params:xml:ns:pidf"
707	         xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
708	         xmlns:mod="urn:ietf:params:xml:ns:pidf:data-model"
709	         entity="pres:someone@example.com">

711	     <tuple id="joi9877866786ua9">
712	       <status>
713	         <basic>open</basic>
714	       </status>
715	       <caps:servcaps>
716	         <caps:audio>true</caps:audio>
717	         <caps:description xml:lang="en">
718	            Example service
719	         </caps:description>
720	         <caps:description xml:lang="hu">
721	            Pe'lda szolga'ltata's
722	         </caps:description>
723	         <caps:duplex>
724	           <caps:supported>
725	             <caps:full/>
726	           </caps:supported>
727	         </caps:duplex>
728	         <caps:message>true</caps:message>
729	         <caps:methods>
730	           <caps:supported>
731	             <caps:ACK/>
732	             <caps:BYE/>
733	             <caps:INVITE/>
734	           </caps:supported>
735	         </caps:methods>
736	         <caps:priority>
737	           <caps:supported>
738	             <caps:lowerthan maxvalue="10"/>
739	           </caps:supported>
740	         </caps:priority>
741	         <caps:schemes>
742	           <caps:supported>
743	             <caps:s>sip</caps:s>
744	           </caps:supported>
745	         </caps:schemes>
746	         <caps:video>false</caps:video>
747	       </caps:servcaps>
748	       <contact>sip:someone@example.com</contact>
749	     </tuple>
750	     <mod:device id="hgt67">
751	       <caps:devcaps>
752	         <caps:mobility>
753	           <caps:supported>
754	             <caps:mobile/>
755	           </caps:supported>
756	         </caps:mobility>
757	       </caps:devcaps>
758	       <mod:deviceID
759	        >urn:uuid:d27459b7-8213-4395-aa77-ed859a3e5b3a</mod:deviceID>
760	     </mod:device>
761	   </presence>

763	6.  XML schema definitions

765	   This section gives the XML schema definitions for the extensions
766	   defined in this document.  Namespace identifier for this schema is
767	   urn:ietf:params:xml:ns:pidf:caps.

769	<?xml version="1.0" encoding="UTF-8"?>
770	<xs:schema xmlns:tns="urn:ietf:params:xml:ns:pidf:caps"
771	  xmlns:xs="http://www.w3.org/2001/XMLSchema"
772	  targetNamespace="urn:ietf:params:xml:ns:pidf:caps"
773	  elementFormDefault="qualified"
774	  attributeFormDefault="unqualified">

776	<!-- This import brings in the XML language
777	     attribute xml:lang-->

779	 <xs:import namespace="http://www.w3.org/XML/1998/namespace"
780	  schemaLocation="http://www.w3.org/2001/xml.xsd"/>

782	<!-- ROOT -->
783	 <xs:element name="servcaps" type="tns:servcapstype"/>
784	 <xs:complexType name="servcapstype">
785	  <xs:sequence>
786	   <xs:element name="actor" type="tns:actortype"
787	    minOccurs="0"/>
788	   <xs:element name="application" type="tns:applicationtype"
789	    minOccurs="0"/>
790	   <xs:element name="audio" type="tns:audiotype" minOccurs="0"/>
791	   <xs:element name="automata" type="tns:automatatype"
792	    minOccurs="0"/>
793	   <xs:element name="class" type="tns:classtype"
794	    minOccurs="0"/>
795	   <xs:element name="control" type="tns:controltype"
796	    minOccurs="0"/>
797	   <xs:element name="data" type="tns:datatype"
798	    minOccurs="0"/>
799	   <xs:element name="description" type="tns:descriptiontype"
800	    minOccurs="0" maxOccurs="unbounded"/>
801	   <xs:element name="duplex" type="tns:duplextype"
802	    minOccurs="0"/>
803	   <xs:element name="event-packages" type="tns:event-packagestype"
804	    minOccurs="0"/>
805	   <xs:element name="extensions" type="tns:extensionstype"
806	    minOccurs="0"/>
807	   <xs:element name="isfocus" type="tns:isfocustype"
808	    minOccurs="0"/>
809	   <xs:element name="message" type="tns:messagetype"
810	    minOccurs="0"/>
811	   <xs:element name="methods" type="tns:methodstype"
812	    minOccurs="0"/>
813	   <xs:element name="languages" type="tns:languagestype"
814	    minOccurs="0"/>
815	   <xs:element name="priority" type="tns:prioritytype"
816	    minOccurs="0"/>
817	   <xs:element name="schemes" type="tns:schemestype"
818	    minOccurs="0"/>
819	   <xs:element name="text" type="tns:texttype"
820	    minOccurs="0"/>
821	   <xs:element name="type" type="tns:typetype"
822	    minOccurs="0" maxOccurs="unbounded"/>
823	   <xs:element name="video" type="tns:videotype"
824	    minOccurs="0"/>
825	   <xs:any namespace="##other" processContents="lax"
826	    minOccurs="0" maxOccurs="unbounded"/>
827	  </xs:sequence>
828	 <xs:anyAttribute namespace="##any" processContents="lax"/>
829	 </xs:complexType>

831	 <xs:element name="devcaps" type="tns:devcaps"/>
832	 <xs:complexType name="devcaps">
833	  <xs:sequence>
834	   <xs:element name="description" type="tns:descriptiontype"
835	    minOccurs="0" maxOccurs="unbounded"/>
836	   <xs:element name="mobility" type="tns:mobilitytype"
837	    minOccurs="0"/>
838	   <xs:any namespace="##other" processContents="lax"
839	    minOccurs="0" maxOccurs="unbounded"/>
840	  </xs:sequence>
841	 <xs:anyAttribute namespace="##any" processContents="lax"/>
842	 </xs:complexType>

844	 <!-- AUDIO -->
845	 <xs:simpleType name="audiotype">
846	  <xs:restriction base="xs:boolean"/>
847	 </xs:simpleType>

849	 <!-- APPLICATION -->
850	 <xs:simpleType name="applicationtype">
851	  <xs:restriction base="xs:boolean"/>
852	 </xs:simpleType>
853	 <!-- DATA -->
854	 <xs:simpleType name="datatype">
855	  <xs:restriction base="xs:boolean"/>
856	 </xs:simpleType>

858	 <!-- CONTROL -->
859	 <xs:simpleType name="controltype">
860	  <xs:restriction base="xs:boolean"/>
861	 </xs:simpleType>

863	 <!-- VIDEO -->
864	 <xs:simpleType name="videotype">
865	  <xs:restriction base="xs:boolean"/>
866	 </xs:simpleType>

868	 <!-- TEXT -->
869	 <xs:simpleType name="texttype">
870	  <xs:restriction base="xs:boolean"/>
871	 </xs:simpleType>

873	 <!-- MESSAGE -->
874	 <xs:simpleType name="messagetype">
875	  <xs:restriction base="xs:boolean"/>
876	 </xs:simpleType>

878	 <!-- TYPE -->
879	 <xs:simpleType name="typetype">
880	  <xs:restriction base="xs:string"/>
881	 </xs:simpleType>

883	 <!-- AUTOMATA -->
884	 <xs:simpleType name="automatatype">
885	  <xs:restriction base="xs:boolean"/>
886	 </xs:simpleType>

888	 <!-- CLASS -->
889	 <xs:complexType name="classtype">
890	  <xs:sequence>
891	   <xs:element name="supported" type="tns:classtypes"
892	    minOccurs="0"/>
893	   <xs:element name="notsupported" type="tns:classtypes"
894	    minOccurs="0"/>
895	  </xs:sequence>
896	 </xs:complexType>
897	 <xs:complexType name="classtypes">
898	  <xs:sequence>
899	   <xs:element name="business" type="xs:string"
900	    minOccurs="0"/>

902	   <xs:element name="personal" type="xs:string"
903	    minOccurs="0"/>
904	   <xs:any namespace="##other" processContents="lax"
905	    minOccurs="0"
906	    maxOccurs="unbounded"/>
907	  </xs:sequence>
908	 </xs:complexType>

910	 <!-- DUPLEX -->
911	 <xs:complexType name="duplextype">
912	  <xs:sequence>
913	   <xs:element name="supported" type="tns:duplextypes"
914	    minOccurs="0"/>
915	   <xs:element name="notsupported" type="tns:duplextypes"
916	    minOccurs="0"/>
917	  </xs:sequence>
918	 </xs:complexType>
919	 <xs:complexType name="duplextypes">
920	  <xs:sequence>
921	   <xs:element name="full" type="xs:string"
922	    minOccurs="0"/>
923	   <xs:element name="half" type="xs:string"
924	    minOccurs="0"/>
925	   <xs:element name="receive-only" type="xs:string"
926	    minOccurs="0"/>
927	   <xs:element name="send-only" type="xs:string"
928	    minOccurs="0"/>
929	   <xs:any namespace="##other" processContents="lax"
930	    minOccurs="0" maxOccurs="unbounded"/>
931	  </xs:sequence>
932	 </xs:complexType>

934	 <!-- DESCRIPTION -->
935	 <xs:complexType name="descriptiontype">
936	  <xs:simpleContent>
937	   <xs:extension base="xs:string">
938	    <xs:attribute ref="xml:lang"/>
939	   </xs:extension>
940	  </xs:simpleContent>
941	 </xs:complexType>

943	 <!-- EVENT-PACKAGES -->
944	 <xs:complexType name="event-packagestype">
945	  <xs:sequence>
946	   <xs:element name="supported" type="tns:eventtypes"
947	    minOccurs="0"/>
948	   <xs:element name="notsupported" type="tns:eventtypes"
949	    minOccurs="0"/>

951	  </xs:sequence>
952	 </xs:complexType>
953	 <xs:complexType name="eventtypes">
954	  <xs:sequence>
955	   <xs:element name="conference" type="xs:string"
956	    minOccurs="0"/>
957	   <xs:element name="dialog" type="xs:string"
958	    minOccurs="0"/>
959	   <xs:element name="kpml" type="xs:string"
960	    minOccurs="0"/>
961	   <xs:element name="message-summary" type="xs:string"
962	    minOccurs="0"/>
963	   <xs:element name="poc-settings" type="xs:string"
964	    minOccurs="0"/>
965	   <xs:element name="presence" type="xs:string"
966	    minOccurs="0"/>
967	   <xs:element name="reg" type="xs:string"
968	    minOccurs="0"/>
969	   <xs:element name="refer" type="xs:string"
970	    minOccurs="0"/>
971	   <xs:element name="Siemens-RTP-Stats"
972	    type="xs:string" minOccurs="0"/>
973	   <xs:element name="spirits-INDPs"
974	    type="xs:string" minOccurs="0"/>
975	   <xs:element name="spirits-user-prof"
976	    type="xs:string" minOccurs="0"/>
977	   <xs:element name="winfo" type="xs:string"
978	    minOccurs="0"/>
979	   <xs:any namespace="##other" processContents="lax"
980	    minOccurs="0" maxOccurs="unbounded"/>
981	  </xs:sequence>
982	 </xs:complexType>

984	 <!-- PRIORITY -->
985	 <xs:complexType name="prioritytype">
986	  <xs:sequence>
987	   <xs:element name="supported" type="tns:prioritytypes"
988	    minOccurs="0"/>
989	   <xs:element name="notsupported" type="tns:prioritytypes"
990	    minOccurs="0"/>
991	  </xs:sequence>
992	 </xs:complexType>
993	 <xs:complexType name="prioritytypes">
994	  <xs:sequence>
995	   <xs:element name="equals" type="tns:equalstype"
996	    minOccurs="0" maxOccurs="unbounded"/>
997	   <xs:element name="higherhan" type="tns:higherthantype"
998	    minOccurs="0" maxOccurs="unbounded"/>

1000	   <xs:element name="lowerthan" type="tns:lowerthantype"
1001	    minOccurs="0" maxOccurs="unbounded"/>
1002	   <xs:element name="range" type="tns:rangetype"
1003	    minOccurs="0" maxOccurs="unbounded"/>
1004	   <xs:any namespace="##other" processContents="lax"
1005	    minOccurs="0" maxOccurs="unbounded"/>
1006	  </xs:sequence>
1007	 </xs:complexType>
1008	 <xs:complexType name="lowerthantype">
1009	  <xs:attribute name="maxvalue" type="xs:integer"
1010	   use="required"/>
1011	 </xs:complexType>
1012	 <xs:complexType name="higherthantype">
1013	  <xs:attribute name="minvalue" type="xs:integer"
1014	   use="required"/>
1015	 </xs:complexType>
1016	 <xs:complexType name="equalstype">
1017	  <xs:attribute name="value" type="xs:integer"
1018	   use="required"/>
1019	 </xs:complexType>
1020	 <xs:complexType name="rangetype">
1021	  <xs:attribute name="minvalue" type="xs:integer"
1022	   use="required"/>
1023	  <xs:attribute name="maxvalue" type="xs:integer"
1024	   use="required"/>
1025	 </xs:complexType>

1027	 <!-- METHODS -->
1028	 <xs:complexType name="methodstype">
1029	  <xs:sequence>
1030	   <xs:element name="supported" type="tns:methodtypes"
1031	    minOccurs="0"/>
1032	   <xs:element name="notsupported" type="tns:methodtypes"
1033	    minOccurs="0"/>
1034	  </xs:sequence>
1035	 </xs:complexType>
1036	 <xs:complexType name="methodtypes">
1037	  <xs:sequence>
1038	   <xs:element name="ACK" type="xs:string" minOccurs="0"/>
1039	   <xs:element name="BYE" type="xs:string" minOccurs="0"/>
1040	   <xs:element name="CANCEL" type="xs:string" minOccurs="0"/>
1041	   <xs:element name="INFO" type="xs:string" minOccurs="0"/>
1042	   <xs:element name="INVITE" type="xs:string" minOccurs="0"/>
1043	   <xs:element name="MESSAGE" type="xs:string" minOccurs="0"/>
1044	   <xs:element name="NOTIFY" type="xs:string" minOccurs="0"/>
1045	   <xs:element name="OPTIONS" type="xs:string" minOccurs="0"/>
1046	   <xs:element name="PRACK" type="xs:string" minOccurs="0"/>
1047	   <xs:element name="PUBLISH" type="xs:string" minOccurs="0"/>
1048	   <xs:element name="REFER" type="xs:string" minOccurs="0"/>
1049	   <xs:element name="REGISTER" type="xs:string" minOccurs="0"/>
1050	   <xs:element name="SUBSCRIBE" type="xs:string" minOccurs="0"/>
1051	   <xs:element name="UPDATE" type="xs:string" minOccurs="0"/>
1052	   <xs:any namespace="##other" processContents="lax" minOccurs="0"
1053	    maxOccurs="unbounded"/>
1054	  </xs:sequence>
1055	 </xs:complexType>

1057	 <!-- EXTENSIONS -->
1058	 <xs:complexType name="extensionstype">
1059	  <xs:sequence>
1060	   <xs:element name="supported" type="tns:extensiontypes"
1061	    minOccurs="0"/>
1062	   <xs:element name="notsupported" type="tns:extensiontypes"
1063	    minOccurs="0"/>
1064	  </xs:sequence>
1065	 </xs:complexType>
1066	 <xs:complexType name="extensiontypes">
1067	  <xs:sequence>
1068	   <xs:element name="rel100" type="xs:string" minOccurs="0"/>
1069	   <xs:element name="early-session" type="xs:string" minOccurs="0"/>
1070	   <xs:element name="eventlist" type="xs:string" minOccurs="0"/>
1071	   <xs:element name="from-change" type="xs:string" minOccurs="0"/>
1072	   <xs:element name="gruu" type="xs:string" minOccurs="0"/>
1073	   <xs:element name="hist-info" type="xs:string" minOccurs="0"/>
1074	   <xs:element name="join" type="xs:string" minOccurs="0"/>
1075	   <xs:element name="norefersub" type="xs:string" minOccurs="0"/>
1076	   <xs:element name="path" type="xs:string" minOccurs="0"/>
1077	   <xs:element name="precondition" type="xs:string" minOccurs="0"/>
1078	   <xs:element name="pref" type="xs:string" minOccurs="0"/>
1079	   <xs:element name="privacy" type="xs:string" minOccurs="0"/>
1080	   <xs:element name="replaces" type="xs:string" minOccurs="0"/>
1081	   <xs:element name="resource-priority" type="xs:string" minOccurs="0"/>
1082	   <xs:element name="sdp-anat" type="xs:string" minOccurs="0"/>
1083	   <xs:element name="sec-agree" type="xs:string" minOccurs="0"/>
1084	   <xs:element name="tdialog" type="xs:string" minOccurs="0"/>
1085	   <xs:element name="timer" type="xs:string" minOccurs="0"/>
1086	   <xs:any namespace="##other" processContents="lax"
1087	    minOccurs="0" maxOccurs="unbounded"/>
1088	  </xs:sequence>
1089	 </xs:complexType>

1091	 <!-- SCHEMES -->
1092	 <xs:complexType name="schemestype">
1093	  <xs:sequence>
1094	   <xs:element name="supported" minOccurs="0">
1095	    <xs:complexType>
1096	     <xs:sequence>
1097	      <xs:element name="s" type="xs:string" maxOccurs="unbounded"/>
1098	     </xs:sequence>
1099	    </xs:complexType>
1100	   </xs:element>
1101	   <xs:element name="notsupported" minOccurs="0">
1102	    <xs:complexType>
1103	     <xs:sequence>
1104	      <xs:element name="s" type="xs:string" maxOccurs="unbounded"/>
1105	     </xs:sequence>
1106	    </xs:complexType>
1107	   </xs:element>
1108	  </xs:sequence>
1109	 </xs:complexType>

1111	 <!-- ACTOR -->
1112	 <xs:complexType name="actortype">
1113	  <xs:sequence>
1114	   <xs:element name="supported" type="tns:actortypes"
1115	    minOccurs="0"/>
1116	   <xs:element name="notsupported" type="tns:actortypes"
1117	    minOccurs="0"/>
1118	  </xs:sequence>
1119	 </xs:complexType>
1120	 <xs:complexType name="actortypes">
1121	  <xs:sequence>
1122	   <xs:element name="attendant" type="xs:string" minOccurs="0"/>
1123	   <xs:element name="information" type="xs:string" minOccurs="0"/>
1124	   <xs:element name="msg-taker" type="xs:string" minOccurs="0"/>
1125	   <xs:element name="principal" type="xs:string" minOccurs="0"/>
1126	   <xs:any namespace="##other" processContents="lax" minOccurs="0"
1127	    maxOccurs="unbounded"/>
1128	  </xs:sequence>
1129	 </xs:complexType>

1131	 <!-- ISFOCUS -->
1132	 <xs:simpleType name="isfocustype">
1133	  <xs:restriction base="xs:boolean"/>
1134	 </xs:simpleType>

1136	 <!-- LANGUAGES -->
1137	 <xs:complexType name="languagestype">
1138	  <xs:sequence>
1139	   <xs:element name="supported" minOccurs="0">
1140	    <xs:complexType>
1141	     <xs:sequence>
1142	      <xs:element name="l" type="xs:string" maxOccurs="unbounded"/>
1143	     </xs:sequence>

1145	    </xs:complexType>
1146	   </xs:element>
1147	   <xs:element name="notsupported" minOccurs="0">
1148	    <xs:complexType>
1149	     <xs:sequence>
1150	      <xs:element name="l" type="xs:string" maxOccurs="unbounded"/>
1151	     </xs:sequence>
1152	    </xs:complexType>
1153	   </xs:element>
1154	  </xs:sequence>
1155	 </xs:complexType>

1157	 <!-- MOBILITY -->
1158	 <xs:complexType name="mobilitytype">
1159	  <xs:sequence>
1160	   <xs:element name="supported" type="tns:mobilitytypes"
1161	    minOccurs="0"/>
1162	   <xs:element name="notsupported" type="tns:mobilitytypes"
1163	    minOccurs="0"/>
1164	  </xs:sequence>
1165	 </xs:complexType>
1166	 <xs:complexType name="mobilitytypes">
1167	  <xs:sequence>
1168	   <xs:element name="fixed" type="xs:string"
1169	    minOccurs="0"/>
1170	   <xs:element name="mobile" type="xs:string"
1171	    minOccurs="0"/>
1172	   <xs:any namespace="##other" processContents="lax" minOccurs="0"
1173	    maxOccurs="unbounded"/>
1174	  </xs:sequence>
1175	 </xs:complexType>
1176	</xs:schema>

1178	                                 Figure 1

1180	7.  IANA Considerations

1182	   This memo calls for IANA to register one new XML namespace URNs as
1183	   defined in [RFC3688].

1185	7.1.   URN sub-namespace registration for
1186	      'urn:ietf:params:xml:ns:pidf:caps'

1188	   URI:
1189	   urn:ietf:params:xml:ns:pidf:caps

1191	   Description:

1193	   This is the XML namespace for XML elements defined by [[[RFCXXXX]]]
1194	   to describe service and device capabilities in application/pidf+xml
1195	   content type.

1197	   Registrant Contact:
1198	   IETF, SIMPLE working group, <simple@ietf.org>
1199	   Mikko Lonnfors, <mikko.lonnfors@nokia.com>

1201	   XML:

1203	   BEGIN
1204	   <?xml version="1.0"?>
1205	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1206	   "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1207	   <html> xmlns="http://www.w3.org/1999/xhtml
1208	   <head>
1209	        <meta http-equiv="content-type"
1210	        content="text/html;charset=iso-8859-1"/>
1211	        <title>Namespace for PIDF user agent capability
1212	               extension</title>
1213	   </head>
1214	   <body>
1215	       <h1>Namespace for PIDF service capability extension</h1>
1216	       <h2>urn:ietf:params:xml:ns:pidf:caps</h2>
1217	       <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
1218	    </body>
1219	    </html>
1220	   END

1222	8.  Security Considerations

1224	   All security considerations specified in [RFC3859] and [RFC3863]
1225	   apply to this document.  Compared to PIDF [RFC3863] this presence
1226	   document format may reveal additional information about user's
1227	   service and device capabilities.  Thus, the PUA SHOULD always obtain
1228	   permission from the user when publishing sensitive information using
1229	   this extension.

1231	9.  Acknowledgments

1233	   Authors of this document would like to thank following people for
1234	   their contributions and valuable comments: Paul Kyzivat, Jonathan
1235	   Rosenberg, Markus Isomaki, Eva Leppanen, Miguel Garcia, Jari
1236	   Urpalainen, and Hisham Khartabil.

1238	10.  References

1240	10.1.  Normative references

1242	   [RFC3859]  Peterson, J., "Common Profile for Presence (CPP)",
1243	              RFC 3859, August 2004.

1245	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1246	              Requirement Levels", BCP 14, RFC 2119, March 1997.

1248	   [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
1249	              W., and J. Peterson, "Presence Information Data Format
1250	              (PIDF)", RFC 3863, August 2004.

1252	   [RFC3840]  Schulzrinne, H., Rosenberg, J., and P. Kyzivat,
1253	              "Indicating User Agent Capabilities in the Session
1254	              Initiation Protocol (SIP)", RFC 3840, August 2004.

1256	   [RFC2913]  Klyne, G., "MIME Content Types in Media Feature
1257	              Expressions", RFC 2913, September 2000.

1259	   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
1260	              Languages", RFC 4646, September 2006.

1262	   [RFC3688]  Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
1263	              January 2004.

1265	   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
1266	              July 2006.

1268	   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1269	              Extensions (MIME) part one: Format of Internet Message
1270	              Bodies", RFC 2045, November 1996.

1272	   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
1273	              Languages", RFC 2277, January 1998.

1275	10.2.  Informative references

1277	   [RFC4569]  Camarillo, G., "Internet Assigned Numbers Authority (IANA)
1278	              Registration of the Message Media Feature Tag", RFC 4569,
1279	              July 2006.

1281	   [RFC3860]  Peterson, J., "Common Profile for Instant Messaging
1282	              (CPIM)", RFC 3860, August 2004.

1284	   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
1285	              Description Protocol", RFC 4566, July 2006.

1287	   [RFC2778]  Day, M., Rosenberg, J., and H. Sugano, "A Model for
1288	              Presence and Instant Messaging", RFC 2778, February 2000.

1290	   [RFC2648]  Moats, R., "A URN namespace for IETF documents", RFC 2648,
1291	              Aug. 1999.

1293	Authors' Addresses

1295	   Mikko Lonnfors
1296	   Nokia
1297	   P.O. Box 321
1298	   Helsinki
1299	   Finland

1301	   Phone: +358 71 8008000
1302	   Email: mikko.lonnfors@nokia.com

1304	   Krisztian Kiss
1305	   Nokia
1306	   313 Fairchild Dr
1307	   Mountain View, CA 94043
1308	   US

1310	   Phone: +1 650 391 5969
1311	   Email: krisztian.kiss@nokia.com

1313	Full Copyright Statement

1315	   Copyright (C) The IETF Trust (2008).

1317	   This document is subject to the rights, licenses and restrictions
1318	   contained in BCP 78, and except as set forth therein, the authors
1319	   retain all their rights.

1321	   This document and the information contained herein are provided on an
1322	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1323	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1324	   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1325	   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1326	   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1327	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1329	Intellectual Property

1331	   The IETF takes no position regarding the validity or scope of any
1332	   Intellectual Property Rights or other rights that might be claimed to
1333	   pertain to the implementation or use of the technology described in
1334	   this document or the extent to which any license under such rights
1335	   might or might not be available; nor does it represent that it has
1336	   made any independent effort to identify any such rights.  Information
1337	   on the procedures with respect to rights in RFC documents can be
1338	   found in BCP 78 and BCP 79.

1340	   Copies of IPR disclosures made to the IETF Secretariat and any
1341	   assurances of licenses to be made available, or the result of an
1342	   attempt made to obtain a general license or permission for the use of
1343	   such proprietary rights by implementers or users of this
1344	   specification can be obtained from the IETF on-line IPR repository at
1345	   http://www.ietf.org/ipr.

1347	   The IETF invites any interested party to bring to its attention any
1348	   copyrights, patents or patent applications, or other proprietary
1349	   rights that may cover technology that may be required to implement
1350	   this standard.  Please address the information to the IETF at
1351	   ietf-ipr@ietf.org.