idnits 2.17.00 (12 Aug 2021)

/tmp/idnits50796/draft-ietf-simple-prescaps-ext-01.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 3667, Section 5.1 on line 16.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 954.

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

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

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

  ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
     960), which is fine, but *also* found old RFC 2026, Section 10.4C,
     paragraph 1 text on line 38.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        By submitting this Internet-Draft, I certify that any applicable patent
        or other IPR claims of which I am aware have been disclosed, or
        will be disclosed, and any of which I become aware will be
        disclosed, in accordance with RFC 3668.


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

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


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

  ** There is 1 instance of lines with control characters in the document.


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

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Line 48 has weird spacing: '...tension  to re...'

  == Line 266 has weird spacing: '...element  indic...'

  == Line 276 has weird spacing: '...element  indic...'

  == Line 694 has weird spacing: '...element  name=...'

  == Line 709 has weird spacing: '...element  name=...'

  == (2 more instances...)

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords. 

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
  -- 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 7, 2004) is 6587 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)

  == Unused Reference: '10' is defined on line 867, but no explicit reference
     was found in the text

  == Unused Reference: '12' is defined on line 874, but no explicit reference
     was found in the text

  == Unused Reference: '14' is defined on line 881, but no explicit reference
     was found in the text

  == Unused Reference: '16' is defined on line 888, but no explicit reference
     was found in the text

  == Unused Reference: '18' is defined on line 896, but no explicit reference
     was found in the text

  == Unused Reference: '19' is defined on line 899, but no explicit reference
     was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '2')

  ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3')

  == Outdated reference: draft-ietf-impp-cpim-pidf has been published as RFC
     3863

  == Outdated reference: draft-ietf-impp-pres has been published as RFC 3859

  == Outdated reference: draft-ietf-sip-callee-caps has been published as RFC
     3840

  == Outdated reference: draft-ietf-sip-callerprefs has been published as RFC
     3841

  == Outdated reference: draft-ietf-impp-im has been published as RFC 3860

  -- Obsolete informational reference (is this intentional?): RFC 3265 (ref.
     '13') (Obsoleted by RFC 6665)

  == Outdated reference: draft-ietf-simple-presence has been published as RFC
     3856

  -- Obsolete informational reference (is this intentional?): RFC 2327 (ref.
     '15') (Obsoleted by RFC 4566)

  -- Obsolete informational reference (is this intentional?): RFC 1766 (ref.
     '18') (Obsoleted by RFC 3066, RFC 3282)

  -- Duplicate reference: RFC2046, mentioned in '19', was also mentioned in
     '16'.


     Summary: 9 errors (**), 0 flaws (~~), 21 warnings (==), 11 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	Expires: November 5, 2004                                          Nokia
5	                                                             May 7, 2004

7	  User Agent Capability Extension to Presence Information Data Format
8	                                 (PIDF)
9	                   draft-ietf-simple-prescaps-ext-01

11	Status of this Memo

13	   By submitting this Internet-Draft, I certify that any applicable
14	   patent or other IPR claims of which I am aware have been disclosed,
15	   and any of which I become aware will be disclosed, in accordance with
16	   RFC 3668.

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
21	   Internet-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 5, 2004.

36	Copyright Notice

38	   Copyright (C) The Internet Society (2004).  All Rights Reserved.

40	Abstract

42	   Interoperation of Instant Messaging and Presence systems has been
43	   defined in the IMPP working group.  The IMPP WG has come up with
44	   baseline interoperable operations and formats for presence and
45	   instant messaging systems.  However, these base formats might need
46	   standardized extensions in order to enable building rational
47	   applications using presence and instant messaging.  This memo
48	   proposes an extension  to represent "Indicating User Agent
49	   Capabilities in the Session Initiation Protocol (SIP)" capabilities
50	   in the Presence Information Document Format (PIDF) compliant presence
51	   documents.

53	Table of Contents

55	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
56	     1.1  Motivation . . . . . . . . . . . . . . . . . . . . . . . .   4
57	     1.2  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
58	   2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   5
59	   3.   Extension for "Indicating User Agent Capabilities in the
60	        Session Initiation Protocol (SIP)" in PIDF documents . . . .   5
61	     3.1  Extension overview . . . . . . . . . . . . . . . . . . . .   5
62	     3.2  <prescaps> element . . . . . . . . . . . . . . . . . . . .   6
63	     3.3  <audio> element  . . . . . . . . . . . . . . . . . . . . .   6
64	     3.4  <application> element  . . . . . . . . . . . . . . . . . .   6
65	     3.5  <data> element . . . . . . . . . . . . . . . . . . . . . .   6
66	     3.6  <control> element  . . . . . . . . . . . . . . . . . . . .   7
67	     3.7  <video> element  . . . . . . . . . . . . . . . . . . . . .   7
68	     3.8  <text> element . . . . . . . . . . . . . . . . . . . . . .   7
69	     3.9  <type> element . . . . . . . . . . . . . . . . . . . . . .   7
70	     3.10   <automata> element . . . . . . . . . . . . . . . . . . .   7
71	     3.11   <class> element  . . . . . . . . . . . . . . . . . . . .   8
72	     3.12   <duplex> element . . . . . . . . . . . . . . . . . . . .   8
73	     3.13   <mobility> element . . . . . . . . . . . . . . . . . . .   8
74	     3.14   <description> element  . . . . . . . . . . . . . . . . .   8
75	     3.15   <event-packages> element . . . . . . . . . . . . . . . .   8
76	       3.15.1   <event-package>  . . . . . . . . . . . . . . . . . .   9
77	     3.16   <priority> element . . . . . . . . . . . . . . . . . . .   9
78	     3.17   <methods> element  . . . . . . . . . . . . . . . . . . .   9
79	       3.17.1   <method> . . . . . . . . . . . . . . . . . . . . . .   9
80	     3.18   <extensions> element . . . . . . . . . . . . . . . . . .  10
81	       3.18.1   <extension>  . . . . . . . . . . . . . . . . . . . .  10
82	     3.19   <schemes> element  . . . . . . . . . . . . . . . . . . .  10
83	       3.19.1   <scheme> . . . . . . . . . . . . . . . . . . . . . .  10
84	     3.20   <actor> element  . . . . . . . . . . . . . . . . . . . .  10
85	     3.21   <is-focus> element . . . . . . . . . . . . . . . . . . .  11
86	     3.22   <languages> element  . . . . . . . . . . . . . . . . . .  11
87	       3.22.1   <language> . . . . . . . . . . . . . . . . . . . . .  11
88	   4.   Publishing and using 'prescaps' elements . . . . . . . . . .  11
89	   5.   Using extension with PIDF document format  . . . . . . . . .  12
90	     5.1  Contact URI  . . . . . . . . . . . . . . . . . . . . . . .  12
91	   6.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  12
92	     6.1  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  13
93	   7.   XML schema definitions . . . . . . . . . . . . . . . . . . .  13
94	   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
95	     8.1  URN sub-namespace registration for
96	          'urn:ietf:params:xml:ns:simple-prescaps-ext' . . . . . . .  18
97	   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  18
98	   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  19
99	   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  19
100	   11.1   Normative references . . . . . . . . . . . . . . . . . . .  19
101	   11.2   Informative references . . . . . . . . . . . . . . . . . .  20
102	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  21
103	        Intellectual Property and Copyright Statements . . . . . . .  22

105	1.  Introduction

107	   Interoperation of instant messaging and presence systems has been
108	   defined in IMPP working group.  Working group has defined "A model
109	   for Presence and Instant Messaging" RFC2778 [2] and also requirements
110	   for protocols implementing such a system in RFC 2779 [3].  Common
111	   presence (CPP) [5] and instant messaging  (CPIM) [11] define common
112	   operations and formats which all  Presence and Instant Messaging
113	   services must agree upon so that basic interoperability would be
114	   possible.  The actual base format for the presence is defined in the
115	   Presence Information Document Format (PIDF) [4].  The PIDF document
116	   format has been designed to reduce the need for gatewaying and to
117	   allow end-to-end security of presence data.  It has taken very
118	   minimalistic approach to support such operations.  In order to make
119	   the PIDF format usable by different presence applications, these
120	   applications usually must extend the basic PIDF format by standard
121	   XML mechanism as defined in the PIDF [4].

123	   The aim of this memo is to introduce SIP/SIMPLE specific extension
124	   mechanism for the PIDF document.  With this extension SIMPLE based
125	   applications can have richer and more usable formats compared to the
126	   baseline PIDF data format.  Aim of this document is to introduce
127	   extension for "Indicating User Agent Capabilities in the Session
128	   Initiation Protocol (SIP)" [6].

130	1.1  Motivation

132	   The PIDF document format [4] defines a <contact> element which may
133	   appear once inside every <tuple> element.  The content of the
134	   <contact>  element encodes the CONTACT ADDRESS and CONTACT MEANS as
135	   defined in RFC2778 [2].  The <contact> element is defined to be an
136	   URI.  This URI can be of any URI type.  In some implementations this
137	   URI can uniquely identify the application the tuple intends to
138	   describe (e.g.  im: URIs usually represent Instant Messaging
139	   service).  However, this may not be the case in all implementations.
140	   For example in SIP, a SIP URI can represent different kinds of
141	   applications.  A SIP URI can be used to contact voice applications,
142	   video applications, or messaging applications.  If it is not known by
143	   other means, it might be hard for applications processing the
144	   presence document containing only SIP URI contact addresses to know
145	   what particular application the tuple intends to describe.  Also
146	   watchers receiving presence information would probably benefit for
147	   getting more descriptive information about what particular
148	   communication means or applications are supported by the presentity.

150	   "Indicating User Agent Capabilities in the Session Initiation
151	   Protocol (SIP)" document [6] defines a set of extensions which allow
152	   callees to express preferences about request handling in SIP servers.

154	   The same information can provide value also to presence watchers so
155	   that they can make more rational decisions on how presentity should
156	   be contacted if presence document would contain similar information
157	   as defined in "Indicating User Agent Capabilities in the Session
158	   Initiation Protocol (SIP)" extension.

160	1.2  Scope

162	   This document defines extension to the PIDF document format which
163	   enables presence implementations based on SIP protocol to utilize
164	   similar capabilities in presence document as what "Indicating User
165	   Agent Capabilities in the Session Initiation Protocol (SIP)" document
166	   [6] defines.

168	   This extension does not replace media negotiation mechanisms defined
169	   for SIP (e.g.  SDP [15]).  This extension is only aimed to give the
170	   watchers hints about the presentity's preferences, willingness and
171	   capabilities to communicate before watchers would initiate
172	   communication with the presentity.

174	2.  Conventions

176	   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
177	   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
178	   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
179	   indicate requirement levels for compliant implementations.

181	   This memo makes use of the vocabulary defined in RFC2778 [2], and in
182	   PIDF [4].

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

187	   This section presents "Indicating User Agent Capabilities in the
188	   Session Initiation Protocol (SIP)" extension namespace, its elements,
189	   their values, and semantics.  This section also describes how this
190	   extension can be further extended.  Extension is intended to be used
191	   with "urn:ietf:params:xml:ns:pidf" namespace and that particular
192	   usage is described here.  This extension may also be used with other
193	   namespaces if appropriate.

195	3.1  Extension overview

197	   This extension adds features presented in "Indicating User Agent
198	   Capabilities in the Session Initiation Protocol (SIP)" document [6]
199	   into the PIDF presence document format.  Extension also includes type
200	   feature tag RFC2913 [7] and language feature tag RFC2987 [8]
201	   definitions.  Features presented in "Indicating User Agent
202	   Capabilities in the Session Initiation Protocol (SIP)"[6], RFC2913
203	   [7], and RFC2987 [8] are used here without any change in their
204	   semantics.  Bringing these features to the PIDF presence document
205	   format basically means mapping them to XML formatted structure.
206	   Namespace identifier for this extension is:

208	   urn:ietf:params:xml:ns:simple-prescaps-ext

210	   When this extension namespace is congregated with the PIDF document,
211	   combined document must follow the same general formatting rules as
212	   specified in the PIDF [4] in Section 4.1.

214	3.2  <prescaps> element

216	   Root element of this extension namespace is <prescaps>.  The root
217	   element MUST be always present.  This element MAY contain one or more
218	   elements as specified later in this document.

220	   <prescaps> element does not have any attributes and it MAY contain
221	   other namespace declarations for the extensions used in the presence
222	   XML document.

224	3.3  <audio> element

226	   The <audio> element indicates that the device supports audio as a
227	   streaming media type as defined in [6].

229	   The <audio> element is of boolean type and does not have any
230	   attributes.  Value 'true' indicates that device supports audio media
231	   type and value 'false' indicates that device does not support audio
232	   media type.

234	3.4  <application> element

236	   The <application> element indicates that the device supports
237	   application as a streaming media type as defined in [6].

239	   The <application> element is of boolean type and does not have any
240	   attributes.  Value 'true' indicates that device supports application
241	   media type and value 'false' indicates that device does not support
242	   application media type.

244	3.5  <data> element

246	   The <data> element indicates that the device supports data as a
247	   streaming media type as defined in [6].

249	   The <data> element is of boolean type and does not have any
250	   attributes.  Value 'true' indicates that device supports data media
251	   type and value 'false' indicates that device does not support data
252	   media type.

254	3.6  <control> element

256	   The <control> element indicates that the device supports control as a
257	   streaming media type as defined in [6].

259	   The <control> element is of boolean type and does not have any
260	   attributes.  Value 'true' indicates that device supports control
261	   media type and value 'false' indicates that device does not support
262	   control media type.

264	3.7  <video> element

266	   The <video> element  indicates that the device supports video as a
267	   streaming media type as defined in [6].

269	   The <video> element is of boolean type and does not have any
270	   attributes.  Value 'true' indicates that device supports video media
271	   type and value 'false' indicates that device does not support video
272	   media type.

274	3.8  <text> element

276	   The <text> element  indicates that the device supports text as a
277	   streaming media type as defined in [6].

279	   The <text> element is of boolean type and does not have any
280	   attributes.  Value 'true' indicates that device supports text media
281	   type and value 'false' indicates that device does not support text
282	   media type.

284	3.9  <type> element

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

290	   The <type> element is of string type and does not have any
291	   attributes.  It must be a string of the form "type/subtype", where
292	   'type' and 'subtype' are defined by the MIME specification RFC2045
293	   [17].  Only lower-case letters should be used.

295	3.10  <automata> element

297	   The <automata> element indicates whether the UA represents an
298	   automata (such as a voicemail server, conference server, IVR, or
299	   recording device) or a human as defined in [6].

301	   The <automata> element is of boolean type and does not have any
302	   attributes.  Value 'true' indicates that the UA represents an
303	   automata and value 'false' indicates that it represents a human.

305	3.11  <class> element

307	   The <class> element indicates the setting, business or personal, in
308	   which a communications device is used as defined in [6].

310	   The <class> element is of string type and does not have any
311	   attributes.  Possible values include: "business" and "personal".

313	3.12  <duplex> element

315	   The <duplex> element lists whether a communications device can
316	   simultaneously send and receive media ("full"), alternate between
317	   sending and receiving ("half"), can only receive ("receive-only") or
318	   only send ("send-only")  defined in [6].

320	   The <duplex> element is of string type and does not have any
321	   attributes.  possible values include: "full", "half", "receive-only",
322	   and "send-only".

324	3.13  <mobility> element

326	   The <mobility> element indicates whether the device is fixed (meaning
327	   that it is associated with a fixed point of contact with the
328	   network), or mobile (meaning that it is not associated with a fixed
329	   point or contact).  Note that cordless phones are fixed, not mobile,
330	   based on this definition.as defined in [6].

332	   The <mobility> element is of string type and does not have any
333	   attributes.  Possible values include: "fixed" and "mobile"

335	3.14  <description> element

337	   The <description> element provides a textual description of the
338	   device as defined in [6].

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

343	3.15  <event-packages> element

345	   The <event-packages> element lists the event packages [13] supported
346	   by a device.

348	   <event-packages> element can contain any number of <event-package>
349	   elements which can be used to describe individual event packages
350	   supported by the device.

352	3.15.1  <event-package>

354	   The <event-package> is string type element and it is used to describe
355	   individual event package supported by the device.  The
356	   <event-package> element can contain 'negated' attribute.  This
357	   attribute is of boolean type.  Value 'true' indicates that device
358	   supports particular event package and value 'false' indicates that
359	   device does not support particular event package as defined in [6].
360	   Default value for 'negated' attribute is 'false'.

362	   The values for this tag equal the event package names that are
363	   registered by each event package as defined in [6].

365	3.16  <priority> element

367	   The <priority> element indicates the call priorities the device is
368	   willing to handle.  A value of X means that the device is willing to
369	   take requests with priority X and higher as defined in [6].

371	   The <priority> element is of integer type does not have any
372	   attributes.

374	3.17  <methods> element

376	   The <methods> element indicates the SIP methods supported by this UA.
377	   In this case, "supported" means that the UA can receive requests with
378	   this method.  In that sense, it has the same connotation as the Allow
379	   header field as defined in [6].

381	   <methods> element can contain any number of <method> elements which
382	   can be used to describe individual methods supported by the device.

384	3.17.1  <method>

386	   The <method> is string type element and it is used to describe
387	   individual method supported by the device.  The <method> element can
388	   contain 'negated' attribute.  This attribute is of boolean type.
389	   Value 'false' indicates that device supports particular method and
390	   value 'true' indicates that device does not support particular method
391	   as defined in [6].  Default value for 'negated' attribute is 'false'.

393	3.18  <extensions> element

395	   The <extensions> element is a list of SIP extensions (each of which
396	   is defined by an option-tag registered with IANA) that are understood
397	   by the UA.  Understood, in this context, means that the option tag
398	   would be included in a Supported header field in a request as defined
399	   in [6].

401	   <extensions> element can contain any number of <extension> elements
402	   which can be used to describe individual extensions supported by the
403	   device.

405	3.18.1  <extension>

407	   The <extension> is string type element and it is used to describe
408	   individual extension supported by the device.  The <extension>
409	   element can contain 'negated' attribute.  This attribute is of
410	   boolean type.  Value 'false' indicates that device supports
411	   particular extension and value 'true' indicates that device does not
412	   support particular extension as defined in [6].  Default value for
413	   'negated' attribute is 'false'.

415	3.19  <schemes> element

417	   The <schemes> element provides the set of URI schemes that are
418	   supported by a UA.  Supported implies, for example, that the UA would
419	   know how to handle a URI of that scheme in the Contact header field
420	   of a redirect response as defined in [6].

422	   <schemes> element can contain any number of <scheme> elements which
423	   can be used to describe individual schemes supported by the device.

425	3.19.1  <scheme>

427	   The <scheme> is string type element and it is used to describe
428	   individual scheme supported by the device.  The <scheme> element can
429	   contain 'negated' attribute.  This attribute is of boolean type.
430	   Value 'false' indicates that device supports particular scheme and
431	   value 'true' indicates that device does not support particular scheme
432	   as defined in [6].  Default value for 'negated' attribute is 'false'.

434	3.20  <actor> element

436	   The <actor> element indicates the type of entity that is available at
437	   this URI as defined in [6].

439	   The <actor> element is of string type and does not have any
440	   attributes.  Possible values include:

442	   o  principal: The device provides communication with the principal
443	      that is associated with the device.  Often this will be a specific
444	      human being, but it can be an automata (for example, when calling
445	      a voice portal).

447	   o  attendant: The device provides communication with an automaton or
448	      person that will act as an intermediary in contacting the
449	      principal associated with the device, or a substitute.

451	   o  msg-taker: The device provides communication with an automaton or
452	      person that will take messages and deliver them to the principal.

454	   o  information: The device provides communication with an automaton
455	      or person that will provide information about the principal.

457	3.21  <is-focus> element

459	   The <is-focus> element indicates that the UA is a conference server,
460	   also known as a focus, and will mix together the media for all calls
461	   to the same URI as defined in [6].

463	   The <is-focus> element is of boolean type and does not have any
464	   attributes.

466	3.22  <languages> element

468	   The <languages> element indicates Ability to display particular human
469	   languages as as defined in [8].

471	   <languages> element can contain any number of <language> elements
472	   which can be used to describe individual languages supported by the
473	   device.

475	3.22.1  <language>

477	   The <language> is string type element and it is used to describe
478	   individual language supported by the device.  The <language> element
479	   can contain 'negated' attribute.  This attribute is of boolean type.
480	   Value 'false' indicates that device supports particular language and
481	   value 'true' indicates that device does not support particular
482	   language as defined in [6].  Default value for 'negated' attribute is
483	   'false'.

485	4.  Publishing and using 'prescaps' elements

487	   In "Indicating User Agent Capabilities in the Session Initiation
488	   Protocol (SIP)" [6] it is recommended that a UA provides complete
489	   information in its contact predicate.  However, it may be that
490	   presentity is not willing to publish presence information which would
491	   be consistent with actual device capabilities (e.g.  presentity may
492	   not want to indicate that he/she supports voice when the device
493	   actually is able to support it).  Also authorization rules or
494	   policies in presence server may limit or modify the published
495	   presence information in a way that all published presence information
496	   may not end up to all possible watchers.

498	   It is RECOMMENTED that Presence User Agent (PUA) using this extension
499	   provides as complete presence information as it can.  However, it is
500	   not mandated that this presence information should be consistent with
501	   actual device capabilities.  Also, watchers should not expect that
502	   presence information represented by this extension fully represents
503	   actual presentity's device capabilities.

505	5.  Using extension with PIDF document format

507	   PIDF format allows use of extension XML namespaces inside <presence>,
508	   <tuple>, and <status> elements.  <presence> element is intended to
509	   describe presentity as a whole.  PIDF extension namespace defined in
510	   this document relates to contact address defined by PIDF <contact>
511	   element to which this extension is applied to.  These contact
512	   addresses can only appear inside <tuple> elements as defined in the
513	   PIDF [4].  PIDF extension namespace defined in this document SHOULD
514	   be placed inside <status> element.  Root element <prescaps> MUST NOT
515	   appear more than once inside a single  <tuple> element but MAY appear
516	   multiple times in PIDF document format inside different <tuple>
517	   elements.

519	5.1  Contact URI

521	   "Indicating User Agent Capabilities in the Session Initiation
522	   Protocol (SIP)" [6]  has restrictions what kind of URIs can be used
523	   with callee capabilities.  As Address of Record of the presentity
524	   represents the union of all presentity's device capabilities it is
525	   RECOMMENTED that contact URI in <contact> element used with this
526	   specifications SHOULD be Address of Record of the presentity.

528	6.  Examples
529	6.1  Example

531	   <?xml version="1.0" encoding="UTF-8"?>
532	   <presence xmlns="urn:ietf:params:xml:ns:pidf"
533	     xmlns:ext="urn:ietf:params:xml:ns:simple-prescaps-ext
534	     entity="pres:someone@example.com">
535	      <tuple id="joi9877866786ua9">
536	        <status>
537	          <basic>open</basic>
538	          <ext:prescaps>
539	          <ext:video>true</ext:video>
540	          <ext:audio>true</ext:video>
541	          <ext:text>false</ext:text>
542	          <ext:mobile>true</ext:mobile>
543	          <ext:methods>
544	           <ext:method>INVITE</ext:method>
545	           <ext:method>MESSAGE</ext:method>
546	           <ext:method>ACK</ext:method>
547	           <ext:method>BYE</ext:method>
548	           <ext:method>CANCEL</ext:method>
549	           <ext:method negated="true">REFER</ext:method>
550	         </ext:methods>
551	       </ext:prescaps>
552	     </status>
553	     <contact>sip:someone@example.com</contact>
554	    </tuple>
555	   </presence>

557	7.  XML schema definitions

559	   This section gives the XML schema definition for the extension
560	   defined in this document.

562	   <?xml version="1.0" encoding="UTF-8"?>
563	   <xs:schema
564	    targetNamespace="urn:ietf:params:xml:ns:simple-prescaps-ext"
565	    xmlns:tns="urn:ietf:params:xml:ns:simple-prescaps-ext"
566	    xmlns:xs="http://www.w3.org/2001/XMLSchema"
567	    elementFormDefault="qualified"
568	    attributeFormDefault="unqualified">
569	   <!-- This import brings in the XML language
570	         attribute xml:lang-->
571	   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
572	    schemaLocation="http://www.w3.org/2001/xml.xsd"/>

574	   <xs:element name="prescaps" type="tns:prescaps"/>
575	   <xs:complexType name="prescaps">
576	     <xs:sequence>
577	       <xs:element name="audio" type="tns:audio" minOccurs="0"/>
578	       <xs:element name="application" type="tns:application"
579	             minOccurs="0"/>
580	       <xs:element name="data" type="tns:data" minOccurs="0"/>
581	       <xs:element name="control" type="tns:control"
582	             minOccurs="0"/>
583	       <xs:element name="video" type="tns:video" minOccurs="0"/>
584	       <xs:element name="text" type="tns:text" minOccurs="0"/>
585	       <xs:element name="automata" type="tns:automata"
586	              minOccurs="0"/>
587	       <xs:element name="class" type="tns:class" minOccurs="0"/>
588	       <xs:element name="duplex" type="tns:duplex" minOccurs="0"/>
589	       <xs:element name="mobility" type="tns:mobility"
590	             minOccurs="0"/>
591	       <xs:element name="description" type="tns:description"
592	             minOccurs="0"/>
593	       <xs:element name="event-packages" type="tns:event-packages"
594	              minOccurs="0"/>
595	       <xs:element name="priority" type="tns:priority"
596	              minOccurs="0"/>
597	       <xs:element name="methods" type="tns:methods"
598	        minOccurs="0"/>
599	       <xs:element name="extensions" type="tns:extensions"
600	             minOccurs="0"/>
601	       <xs:element name="schemes" type="tns:schemes"
602	       		 minOccurs="0"/>
603	       <xs:element name="actor" type="tns:actor" minOccurs="0"
604	              maxOccurs="4"/>
605	       <xs:element name="is-focus" type="tns:is-focus"
606	        minOccurs="0"/>
607	       <xs:element name="languages" type="tns:languages"
608	        minOccurs="0"
609	              maxOccurs="unbounded"/>
610	       <xs:any namespace="##other" processContents="lax"
611	       minOccurs="0" maxOccurs="unbounded"/>
612	     </xs:sequence>
613	   </xs:complexType>

615	   <xs:complexType name="audio">
616	     <xs:restriction base="xs:boolean"/>
617	   </xs:complexType>

619	   <xs:complexType name="application">
620	     <xs:restriction base="xs:boolean"/>
621	   </xs:complexType>
622	   <xs:complexType name="data">
623	     <xs:restriction base="xs:boolean"/>
624	   </xs:complexType>

626	   <xs:complexType name="control">
627	     <xs:restriction base="xs:boolean"/>
628	   </xs:complexType>

630	   <xs:complexType name="video">
631	     <xs:restriction base="xs:boolean"/>
632	   </xs:complexType>

634	   <xs:complexType name="text">
635	     <xs:restriction base="xs:boolean"/>
636	   </xs:complexType>

638	   <xs:simpleType name="type">
639	     <xs:restriction base="xs:string"/>
640	   </xs:simpleType>

642	   <xs:simpleType name="automata">
643	     <xs:restriction base="xs:boolean"/>
644	   </xs:simpleType>

646	   <xs:simpleType name="class">
647	     <xs:restriction base="xs:string">
648	   <xs:enumeration value="personal"/>
649	   <xs:enumeration value="business"/>
650	     </xs:restriction>
651	   </xs:simpleType>

653	   <xs:simpleType name="duplex">
654	     <xs:restriction base="xs:string">
655	   <xs:enumeration value="full"/>
656	   <xs:enumeration value="half"/>
657	   <xs:enumeration value="receive-only"/>
658	   <xs:enumeration value="send-only"/>
659	     </xs:restriction>
660	   </xs:simpleType>

662	   <xs:simpleType name="mobility">
663	     <xs:restriction base="xs:string">
664	     <xs:enumeration value="fixed"/>
665	   <xs:enumeration value="mobile"/>
666	     </xs:restriction>
667	   </xs:simpleType>

669	   <xs:simpleType name="description">
670	     <xs:restriction base="xs:string"/>
671	   </xs:simpleType>

673	   <xs:complexType name="event-packages">
674	     <xs:sequence>
675	   <xs:element name="event-package" type="tns:event-package"
676	     minOccurs="0" maxOccurs="unbounded"/>
677	     </xs:sequence>
678	   </xs:complexType>

680	   <xs:complexType name="event-package">
681	     <xs:simpleContent>
682	   <xs:extension base="xs:string">
683	     <xs:attribute name="negated" type="xs:boolean"/>
684	   </xs:extension>
685	     </xs:simpleContent>
686	   </xs:complexType>

688	   <xs:simpleType name="priority">
689	     <xs:restriction base="xs:integer"/>
690	   </xs:simpleType>

692	   <xs:complexType name="methods">
693	     <xs:sequence>
694	   <xs:element  name="method" type="tns:method"
695	     minOccurs="0" maxOccurs="unbounded"/>
696	     </xs:sequence>
697	   </xs:complexType>

699	   <xs:complexType name="method">
700	     <xs:simpleContent>
701	   <xs:extension base="xs:string">
702	     <xs:attribute name="negated" type="xs:boolean"/>
703	   </xs:extension>
704	     </xs:simpleContent>
705	   </xs:complexType>

707	   <xs:complexType name="extensions">
708	     <xs:sequence>
709	   <xs:element  name="extension" type="tns:extension"
710	     minOccurs="0" maxOccurs="unbounded"/>
711	     </xs:sequence>
712	   </xs:complexType>

714	   <xs:complexType name="extension">
715	     <xs:simpleContent>
716	   <xs:extension base="xs:string">
717	     <xs:attribute name="negated" type="xs:boolean"/>

719	   </xs:extension>
720	     </xs:simpleContent>
721	   </xs:complexType>

723	   <xs:complexType name="schemes">
724	     <xs:sequence>
725	   <xs:element  name="scheme" type="tns:scheme"
726	     minOccurs="0" maxOccurs="unbounded"/>
727	     </xs:sequence>
728	   </xs:complexType>

730	   <xs:complexType name="scheme">
731	     <xs:simpleContent>
732	   <xs:extension base="xs:string">
733	     <xs:attribute name="negated" type="xs:boolean"/>
734	   </xs:extension>
735	     </xs:simpleContent>
736	   </xs:complexType>

738	   <xs:simpleType name="actor">
739	     <xs:restriction base="xs:string">
740	   <xs:enumeration value="principal"/>
741	   <xs:enumeration value="attendant"/>
742	   <xs:enumeration value="msg-taker"/>
743	   <xs:enumeration value="information"/>
744	     </xs:restriction>
745	   </xs:simpleType>

747	   <xs:simpleType name="is-focus">
748	     <xs:restriction base="xs:boolean"/>
749	   </xs:simpleType>

751	   <xs:complexType name="languages">
752	     <xs:sequence>
753	   <xs:element  name="language" type="tns:language"
754	     minOccurs="0" maxOccurs="unbounded"/>
755	     </xs:sequence>
756	   </xs:complexType>

758	   <xs:complexType name="language">
759	     <xs:simpleContent>
760	   <xs:extension base="xs:string">
761	     <xs:attribute name="negated" type="xs:boolean"/>
762	   </xs:extension>
763	     </xs:simpleContent>
764	   </xs:complexType>

766	   </xs:schema>
767	                                Figure 2

769	8.  IANA Considerations

771	   This memo calls for IANA to register a new XML namespace URN as
772	   defined in [9]

774	8.1   URN sub-namespace registration for
775	    'urn:ietf:params:xml:ns:simple-prescaps-ext'

777	   URI:
778	   urn:ietf:params:xml:ns:simple-prescaps-ext

780	   Description:
781	   This is the XML namespace for XML elements defined by [[[RFCXXXX]]]
782	   to describe user agent capability extension for PIDF presence
783	   document format in application/pidf+xml content type.

785	   Registrant Contact:
786	   IETF, SIMPLE working group, <simple@ietf.org>
787	   Mikko Lonnfors, <mikko.lonnfors@nokia.com>

789	   XML:

791	   BEGIN
792	   <?xml version="1.0"?>
793	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
794	   "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
795	   <html xmlns="http://www.w3.org/1999/xhtml
796	   <head>
797	        <meta http-equiv="content-type"
798	        content="text/html;charset=iso-8859-1"/>
799	        <title>User agent capability extension to the Presence
800	          information data format (PIDF)</title>
801	   </head>
802	   <body>
803	       <h1>Namespace for PIDF user agent capability extension</h1>
804	       <h2>urn:ietf:params:xml:ns:simple-prescaps-ext</h2>
805	       <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
806	    </body>
807	    </html>
808	   END

810	9.  Security Considerations

812	   All security considerations specified in CPIM [5] and in PIDF [4]
813	   documents apply to this document.  Compared to PIDF [4] this presence
814	   document format may reveal additional information about user's device
815	   capabilities.

817	   Because presence is very privacy-sensitive information, the transport
818	   protocol for the presence information SHOULD have capabilities to
819	   protect protocol messages from possible threats, such as
820	   eavesdropping, corruption, tamper and replay attacks.  The protocols
821	   SHOULD be able to use security mechanisms which are standardized or
822	   being standardized in IETF.  However, it depends on the actual
823	   transport protocols which security mechanisms should be used, and it
824	   is beyond the scope of this memo.

826	10.  Acknowledgments

828	   Authors of this document would like to thank following people for
829	   their contributions and valuable comments: Paul Kyzivat, Jonathan
830	   Rosenberg, Markus Isomaki, Eva Leppanen, and Hisham Khartabil.

832	11.  References

834	11.1  Normative references

836	   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
837	        Levels", BCP 14, RFC 2119, March 1997.

839	   [2]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
840	        Instant Messaging", RFC 2778, February 2000.

842	   [3]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant
843	        Messaging / Presence Protocol Requirements", RFC 2779, February
844	        2000.

846	   [4]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
847	        J. Peterson, "Presence Information Data Format (PIDF)",
848	        draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.

850	   [5]  Peterson, J., "Common Profile for Presence (CPP)",
851	        draft-ietf-impp-pres-04 (work in progress), August 2003.

853	   [6]  Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Indicating User
854	        Agent Capabilities in the Session Initiation Protocol (SIP)",
855	        draft-ietf-sip-callee-caps-03 (work in progress), December 2003.

857	   [7]  Klyne, G., "MIME Content Types in Media Feature Expressions",
858	        RFC 2913, September 2000.

860	   [8]  Hoffman, P., "Registration of Charset and Languages Media
861	        Features Tags", RFC 2987, November 2000.

863	   [9]  Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

865	11.2  Informative references

867	   [10]  Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Caller
868	         Preferences for the Session Initiation Protocol (SIP)",
869	         draft-ietf-sip-callerprefs-10 (work in progress), October 2003.

871	   [11]  Peterson, J., "Common Profile for Instant Messaging (CPIM)",
872	         draft-ietf-impp-im-04 (work in progress), August 2003.

874	   [12]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
875	         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
876	         Session Initiation Protocol", RFC 3261, June 2002.

878	   [13]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
879	         Notification", RFC 3265, June 2002.

881	   [14]  Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
882	         for Presence",  draft-ietf-simple-presence-10.txt (work in
883	         progress), May 2002.

885	   [15]  Handley, M. and V. Jacobson, "SDP: Session Description
886	         Protocol", RFC 2327, April 1998.

888	   [16]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
889	         Extensions (MIME) part two: Media Types", RFC 2046, November
890	         1996.

892	   [17]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
893	         Extensions (MIME) part one:Format of Internet Message Bodies",
894	         RFC 2045, November 1996.

896	   [18]  Alvestrand, H., "Tags for the Identification of Languages", RFC
897	         1766, March 1995.

899	   [19]  Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
900	         Registration Procedure", RFC 2046, March 1999.

902	Authors' Addresses

904	   Mikko Lonnfors
905	   Nokia
906	   Itamerenkatu 11-13 00180
907	   Helsinki
908	   Finland

910	   Phone: +358 71 8008000
911	   EMail: mikko.lonnfors@nokia.com

913	   Krisztian Kiss
914	   Nokia
915	   12278 Scripps Summit Drive
916	   San Diego
917	   US

919	   Phone: +18582049141
920	   EMail: krisztian.kiss@nokia.com

922	Intellectual Property Statement

924	   The IETF takes no position regarding the validity or scope of any
925	   Intellectual Property Rights or other rights that might be claimed to
926	   pertain to the implementation or use of the technology described in
927	   this document or the extent to which any license under such rights
928	   might or might not be available; nor does it represent that it has
929	   made any independent effort to identify any such rights.  Information
930	   on the procedures with respect to rights in RFC documents can be
931	   found in BCP 78 and BCP 79.

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

940	   The IETF invites any interested party to bring to its attention any
941	   copyrights, patents or patent applications, or other proprietary
942	   rights that may cover technology that may be required to implement
943	   this standard.  Please address the information to the IETF at
944	   ietf-ipr@ietf.org.

946	Disclaimer of Validity

948	   This document and the information contained herein are provided on an
949	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
950	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
951	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
952	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
953	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
954	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

956	Copyright Statement

958	   Copyright (C) The Internet Society (2004).  This document is subject
959	   to the rights, licenses and restrictions contained in BCP 78, and
960	   except as set forth therein, the authors retain all their rights.

962	Acknowledgment

964	   Funding for the RFC Editor function is currently provided by the
965	   Internet Society.