idnits 2.17.1
draft-ietf-simple-xcap-list-usage-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
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 are 6 instances of too long lines in the document, the longest one
being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== 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 (October 27, 2003) is 7487 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: '8' is defined on line 425, but no explicit reference
was found in the text
== Unused Reference: '10' is defined on line 432, but no explicit reference
was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141)
** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5')
== Outdated reference: A later version (-12) exists of
draft-ietf-simple-xcap-00
-- Obsolete informational reference (is this intentional?): RFC 3265 (ref.
'10') (Obsoleted by RFC 6665)
== Outdated reference: A later version (-07) exists of
draft-ietf-simple-event-list-04
Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 SIMPLE J. Rosenberg
2 Internet-Draft dynamicsoft
3 Expires: April 26, 2004 October 27, 2003
5 An Extensible Markup Language (XML) Configuration Access Protocol
6 (XCAP) Usage for Resource Lists
7 draft-ietf-simple-xcap-list-usage-01
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet-Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at http://
24 www.ietf.org/ietf/1id-abstracts.txt.
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
29 This Internet-Draft will expire on April 26, 2004.
31 Copyright Notice
33 Copyright (C) The Internet Society (2003). All Rights Reserved.
35 Abstract
37 This document describes a usage of the Extensible Markup Language
38 (XML) Configuration Access Protocol (XCAP) for manipulating lists of
39 resources. These lists can be used as presence lists (also known as
40 buddy lists or rosters), but this specification does not restrict
41 their usage to that.
43 Table of Contents
45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
47 3. Application Unique ID . . . . . . . . . . . . . . . . . . . 5
48 4. Structure of a Resource List . . . . . . . . . . . . . . . . 6
49 5. Resource Interdependencies . . . . . . . . . . . . . . . . . 8
50 6. Additional Constraints . . . . . . . . . . . . . . . . . . . 9
51 7. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 10
52 8. Authorization Policies . . . . . . . . . . . . . . . . . . . 11
53 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 12
54 10. Example Document . . . . . . . . . . . . . . . . . . . . . . 14
55 11. Security Considerations . . . . . . . . . . . . . . . . . . 15
56 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
57 12.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . . 16
58 12.2 application/resource-lists+xml MIME Type . . . . . . . . . . 16
59 12.3 URN Sub-Namespace Registration for
60 urn:ietf:params:xml:ns:resource-lists . . . . . . . . . . . 17
61 Normative References . . . . . . . . . . . . . . . . . . . . 18
62 Informative References . . . . . . . . . . . . . . . . . . . 19
63 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
64 Intellectual Property and Copyright Statements . . . . . . . 20
66 1. Introduction
68 In many communications applications, it is neccesary for the network
69 to have access to a list of resources that represent a group that the
70 user would like to apply an action to. One such example is a presence
71 list [13]. These lists are used by Session Initiation Protocol (SIP)
72 for Instant Messaging and Presence (SIMPLE) [9]Resource List Servers
73 (RLS) [11] for processing list subscriptions. Another example might
74 be list of recipients for an instant message, or a list of users to
75 invite to a conference bridge.
77 Generally, these lists will need to be manipulated by the end users
78 of the system, and used by servers in the network. To support such
79 manipulations, the XML Configuration Access Protocol (XCAP) [7] has
80 been defined. XCAP requires application usages to standardize several
81 pieces of information, including an application unique ID (AUID), an
82 XML schema, and various other pieces of information. This
83 specification fulfills those requirements.
85 The XML schema defined here has several other usages outside of XCAP:
87 1. A PC client application will need to know the users in the
88 presence list, so that it can generate a subscription to each
89 one. This information represents user provisioned data for the
90 application. Typically, this information is stored on local disk
91 in a proprietary file format. By defining a standard format, the
92 same list can be used by a multiplicity of different client
93 applications, providing portability across them.
95 2. It is common for users to share presence lists. As an example,
96 user A may have three people in their list that they wish to tell
97 user B about. User A would like to send an email to user B with
98 an attachment describing these three people. Should user B open
99 the attachment, the three people can be added to their own
100 presence list. Doing this requires a standardized format for
101 exchanging lists over email, instant messaging, and other
102 communications protocols.
104 2. Terminology
106 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
108 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
109 indicate requirement levels for compliant implementations.
111 3. Application Unique ID
113 XCAP requires application usages to define a unique application usage
114 ID (AUID) in either the IETF tree or a vendor tree. This
115 specification defines the "resource-lists" AUID within the IETF tree,
116 via the IANA registration in Section 12.
118 4. Structure of a Resource List
120 A resource list is an XML [2] document that MUST be well-formed and
121 SHOULD be valid. Resource list documents MUST be based on XML 1.0 and
122 MUST be encoded using UTF-8. This specification makes use of XML
123 namespaces for identifying resource list documents and document
124 fragments. The namespace URI for elements defined by this
125 specification is a URN [3], using the namespace identifier 'ietf'
126 defined by [5] and extended by [6]. This URN is:
128 urn:ietf:params:xml:ns:resource-lists
130 A resource list document begins with the root element tag
131 ``resource-lists''. It consists of any number of ``list''
132 sub-elements, each of which is a resource list. Other elements from
133 different namespaces MAY be present for the purposes of
134 extensibility; elements or attributes from unknown namespaces MUST be
135 ignored. There are three attributes associated with this element. The
136 first, "name", MUST be present:
138 name: This attribute is a descriptive name for the list. It MUST
139 be unique amongst all other list elements within the same parent
140 element.
142 Each list element will also have boolean attributes which indicate a
143 specific action that may be made against that list. This
144 specification defines a single attribute - subscribeable - which
145 indicates that the list may be subscribed to using the SIP event list
146 specification [11]. Extensions to this application usage MAY define
147 additional boolean elements, each within a different namespace, for
148 the purposes of indicating other actions that may be peformed. When
149 an attribute is absent, it implies that the operation is not
150 supported.
152 The third other attribute, "uri" MAY be present. It provides a URI
153 that can be used to access the list, for example, using the SIP event
154 notification extension for lists [11]. As a result, the URI MUST be
155 either a SIP URI or a pres URI [12].
157 Each list element is composed of a sequence of entry elements, list
158 elements, external elements. The ability of a list element to contain
159 other list elements means that a resource list can be hierarchically
160 structured. An entry element describes a single presentity that is
161 part of the list. An external element contains a reference to a list
162 stored on another server. A list element can also contain elements
163 from other namespaces, for the purposes of extensibility.
165 The entry element describes a single resource. The entry element has
166 two attributes:
168 name: This mandatory attribute is a unique identifier amongst all
169 other entry elements of the same parent.
171 uri: This optional attribute is a URI that is used to access the
172 resource. It MUST be either a SIP or pres URI.
174 The entry element contains a sequence of other elements. Only one
175 such element is defined at this time, which is the display-name. This
176 element provides a UTF-8 encoded string, meant for consumption by the
177 user, that describes the resource. Unlike the "name" attribute of the
178 entry element, the display-name has no uniqueness requirements. Other
179 elements from other namespaces MAY be included. This is meant to
180 support the inclusion of other information about the entry, such as a
181 phone number or postal address.
183 5. Resource Interdependencies
185 An XCAP server supporting this application usage need only worry
186 about a single data interdependency - the "uri" attribute of the list
187 element.
189 If the "uri" attribute is absent in a document written to an XCAP
190 server, but the "subscribeable" flag is true, the XCAP server MUST
191 allocate a URI for this list. This allocated URI MUST be globally
192 unique, and MUST route to an RLS which will handle list subscriptions
193 for the list defined by the document. The server MUST set the uri
194 attribute of the document with this URI.
196 A server MUST NOT delete the "uri" attribute, however, should a
197 client change the subscribeable flag to false after the server has
198 allocated a URI.
200 6. Additional Constraints
202 There are no constraints on the document beyond those described in
203 the schema.
205 7. Naming Conventions
207 There are no naming conventions that need to be defined for this
208 application usage. A subscription to a resource list will be to a
209 specific URI. That URI will be one of the "uri" attributes defined in
210 a list within one of the documents managed by an XCAP server.
212 8. Authorization Policies
214 This application usage does not modify the default XCAP authorization
215 policy, which is that only a user can read, write or modify their own
216 documents. A server can allow priveleged users to modify documents
217 that they don't own, but the establishment and indication of such
218 policies is outside the scope of this document. It is anticipated
219 that a future application usage will define which users are allowed
220 to modify a list resource.
222 9. XML Schema
224 The following is the XML schema definition of the resource list:
226
227
283
298
288
297
See RFCXXXX.
394 395 396 END 398 Normative References 400 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 401 Levels", BCP 14, RFC 2119, March 1997. 403 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 404 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 405 REC-xml-20001006, October 2000. 407 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 409 [4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 410 3023, January 2001. 412 [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 413 August 1999. 415 [6] Mealling, M., "The IETF XML Registry", 416 draft-mealling-iana-xmlns-registry-05 (work in progress), June 417 2003. 419 [7] Rosenberg, J., "The Extensible Markup Language (XML) 420 Configuration Access Protocol (XCAP)", 421 draft-ietf-simple-xcap-00 (work in progress), June 2003. 423 Informative References 425 [8] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 426 Instant Messaging", RFC 2778, February 2000. 428 [9] Rosenberg, J., "A Presence Event Package for the Session 429 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 430 in progress), January 2003. 432 [10] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 433 Notification", RFC 3265, June 2002. 435 [11] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 436 Protocol (SIP) Event Notification Extension for Resource 437 Lists", draft-ietf-simple-event-list-04 (work in progress), 438 June 2003. 440 [12] Peterson, J., "Common Profile for Presence (CPP)", 441 draft-ietf-impp-pres-04 (work in progress), October 2003. 443 [13] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of 444 Data Elements in Session Initiation Protocol (SIP) for Instant 445 Messaging and Presence Leveraging Extensions (SIMPLE) Systems", 446 draft-ietf-simple-data-req-03 (work in progress), June 2003. 448 Author's Address 450 Jonathan Rosenberg 451 dynamicsoft 452 600 Lanidex Plaza 453 Parsippany, NJ 07052 454 US 456 Phone: +1 973 952-5000 457 EMail: jdrosen@dynamicsoft.com 458 URI: http://www.jdrosen.net 460 Intellectual Property Statement 462 The IETF takes no position regarding the validity or scope of any 463 intellectual property or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; neither does it represent that it 467 has made any effort to identify any such rights. Information on the 468 IETF's procedures with respect to rights in standards-track and 469 standards-related documentation can be found in BCP-11. Copies of 470 claims of rights made available for publication and any assurances of 471 licenses to be made available, or the result of an attempt made to 472 obtain a general license or permission for the use of such 473 proprietary rights by implementors or users of this specification can 474 be obtained from the IETF Secretariat. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights which may cover technology that may be required to practice 479 this standard. Please address the information to the IETF Executive 480 Director. 482 Full Copyright Statement 484 Copyright (C) The Internet Society (2003). All Rights Reserved. 486 This document and translations of it may be copied and furnished to 487 others, and derivative works that comment on or otherwise explain it 488 or assist in its implementation may be prepared, copied, published 489 and distributed, in whole or in part, without restriction of any 490 kind, provided that the above copyright notice and this paragraph are 491 included on all such copies and derivative works. However, this 492 document itself may not be modified in any way, such as by removing 493 the copyright notice or references to the Internet Society or other 494 Internet organizations, except as needed for the purpose of 495 developing Internet standards in which case the procedures for 496 copyrights defined in the Internet Standards process must be 497 followed, or as required to translate it into languages other than 498 English. 500 The limited permissions granted above are perpetual and will not be 501 revoked by the Internet Society or its successors or assignees. 503 This document and the information contained herein is provided on an 504 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 505 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 506 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 507 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 508 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 510 Acknowledgement 512 Funding for the RFC Editor function is currently provided by the 513 Internet Society.