idnits 2.17.00 (12 Aug 2021) /tmp/idnits46511/draft-ietf-simple-xcap-05.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2613. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 18 instances of too long lines in the document, the longest one being 9 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 == Line 2493 has weird spacing: '...Changes in XM...' == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the creation or insertion was successful, and the resource interdependencies are resolved, the server returns a 200 OK or 201 Created, as appropriate. If the client included "application/xcap-diff+xml" in an Accept header in the PUT request, and the request was an insertion resulting in a 201 response, the server SHOULD include an XCAP diff document in the response [4]. The XCAP diff document SHOULD contain a single element. It SHOULD indicate the entity tag for the document resource prior to the insertion in the "previous-etag" attribute, and the entity tag for the document after insertion in the "new-etag" attribute. A 200 OK response to PUT MUST not contain any content. -- 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 (November 16, 2004) is 6394 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-03) exists of draft-ietf-simple-xcap-package-02 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2616 (ref. '5') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2048 (ref. '7') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2617 (ref. '10') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2234 (ref. '11') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. '12') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 2818 (ref. '13') == Outdated reference: draft-ietf-simple-event-list has been published as RFC 4662 == Outdated reference: draft-ietf-simple-xcap-list-usage has been published as RFC 4826 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '26') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '27') (Obsoleted by RFC 6665) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: May 17, 2005 November 16, 2004 5 The Extensible Markup Language (XML) Configuration Access Protocol 6 (XCAP) 7 draft-ietf-simple-xcap-05 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she 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 May 17, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This specification defines the Extensible Markup Language (XML) 43 Configuration Access Protocol (XCAP). XCAP allows a client to read, 44 write and modify application configuration data, stored in XML format 45 on a server. XCAP maps XML document sub-trees and element attributes 46 to HTTP URLs, so that these components can be directly accessed by 47 HTTP. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Application Usages . . . . . . . . . . . . . . . . . . . . . 7 56 5.1 Application Unique ID (AUID) . . . . . . . . . . . . . . . 7 57 5.2 Data Validation . . . . . . . . . . . . . . . . . . . . . 8 58 5.3 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 9 59 5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 9 60 5.5 Resource Interdependencies . . . . . . . . . . . . . . . . 10 61 5.6 Authorization Policies . . . . . . . . . . . . . . . . . . 10 62 5.7 Data Extensibility . . . . . . . . . . . . . . . . . . . . 11 63 5.8 Documenting Application Usages . . . . . . . . . . . . . . 11 64 5.9 Guidelines for Creating Application Usages . . . . . . . . 12 65 6. URL Construction . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1 XCAP Root . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.2 Document Selector . . . . . . . . . . . . . . . . . . . . 14 68 6.3 Node Selector . . . . . . . . . . . . . . . . . . . . . . 15 69 7. Client Operations . . . . . . . . . . . . . . . . . . . . . 20 70 7.1 Create or Replace a Document . . . . . . . . . . . . . . . 22 71 7.2 Delete a Document . . . . . . . . . . . . . . . . . . . . 22 72 7.3 Fetch a Document . . . . . . . . . . . . . . . . . . . . . 22 73 7.4 Create or Replace an Element . . . . . . . . . . . . . . . 22 74 7.5 Delete an Element . . . . . . . . . . . . . . . . . . . . 24 75 7.6 Fetch an Element . . . . . . . . . . . . . . . . . . . . . 25 76 7.7 Create or Replace an Attribute . . . . . . . . . . . . . . 25 77 7.8 Delete an Attribute . . . . . . . . . . . . . . . . . . . 26 78 7.9 Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 27 79 7.10 Conditional Operations . . . . . . . . . . . . . . . . . 27 80 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 29 81 8.1 POST Handling . . . . . . . . . . . . . . . . . . . . . . 29 82 8.2 PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 30 83 8.2.1 Locating the Parent . . . . . . . . . . . . . . . . . 30 84 8.2.2 Verifying Document Content . . . . . . . . . . . . . . 31 85 8.2.3 Creation . . . . . . . . . . . . . . . . . . . . . . . 31 86 8.2.4 Replacement . . . . . . . . . . . . . . . . . . . . . 32 87 8.2.5 Validation . . . . . . . . . . . . . . . . . . . . . . 33 88 8.2.6 Resource Interdependencies . . . . . . . . . . . . . . 34 89 8.3 GET Handling . . . . . . . . . . . . . . . . . . . . . . . 34 90 8.4 DELETE Handling . . . . . . . . . . . . . . . . . . . . . 35 91 8.5 Managing Etags . . . . . . . . . . . . . . . . . . . . . . 36 92 9. Cache Control . . . . . . . . . . . . . . . . . . . . . . . 36 93 10. Detailed Conflict Reports . . . . . . . . . . . . . . . . . 36 94 10.1 Document Structure . . . . . . . . . . . . . . . . . . . 36 95 10.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 38 96 11. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . 41 97 11.1 Application Usage ID (AUID) . . . . . . . . . . . . . . 41 98 11.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 41 99 11.3 MIME Type . . . . . . . . . . . . . . . . . . . . . . . 43 100 11.4 Validation Constraints . . . . . . . . . . . . . . . . . 43 101 11.5 Data Semantics . . . . . . . . . . . . . . . . . . . . . 43 102 11.6 Naming Conventions . . . . . . . . . . . . . . . . . . . 43 103 11.7 Resource Interdependencies . . . . . . . . . . . . . . . 43 104 11.8 Authorization Policies . . . . . . . . . . . . . . . . . 43 105 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44 106 13. Security Considerations . . . . . . . . . . . . . . . . . . 46 107 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 47 108 14.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . 47 109 14.2 MIME Types . . . . . . . . . . . . . . . . . . . . . . . 48 110 14.2.1 application/xcap-el+xml MIME Type . . . . . . . . . 48 111 14.2.2 application/xcap-att+xml MIME Type . . . . . . . . . 49 112 14.2.3 application/xcap-error+xml MIME Type . . . . . . . . 50 113 14.2.4 application/xcap-caps+xml MIME Type . . . . . . . . 51 114 14.3 URN Sub-Namespace Registrations . . . . . . . . . . . . 52 115 14.3.1 urn:ietf:params:xml:ns:xcap-error . . . . . . . . . 52 116 14.3.2 urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . 52 117 14.4 XML Schema Registrations . . . . . . . . . . . . . . . . 53 118 14.4.1 XCAP Error Schema Registration . . . . . . . . . . . 53 119 14.4.2 XCAP Capabilities Schema Registration . . . . . . . 53 120 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 121 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 122 16.1 Normative References . . . . . . . . . . . . . . . . . . . 54 123 16.2 Informative References . . . . . . . . . . . . . . . . . . 55 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . 56 125 Intellectual Property and Copyright Statements . . . . . . . 57 127 1. Introduction 129 In many communications applications, such as Voice over IP, instant 130 messaging, and presence, it is necessary for network servers to 131 access per-user information in the process of servicing a request. 132 This per-user information resides within the network, but is managed 133 by the end user themselves. Its management can be done through a 134 multiplicity of access points, including the web, a wireless handset, 135 or a PC application. 137 Examples of per-user information are presence [18] authorization 138 policy and presence lists. Presence lists are lists of users whose 139 presence is desired by a watcher [25]. One way to obtain presence 140 information for the list is to subscribe to a resource which 141 represents that list [19]. In this case, the Resource List Server 142 (RLS) requires access to this list in order to process a SIP 143 [15]SUBSCRIBE [27] request for it. Another way to obtain presence 144 for the users on the list is for a watcher to subscribe to each user 145 individually. In that case, it is convenient to have a server store 146 the list, and when the client boots, it fetches the list from the 147 server. This would allow a user to access their resource lists from 148 different clients. 150 Requirements for manipulation of presence lists and authorization 151 policies have been specified by the SIMPLE working group [20]. 153 This specification describes a protocol that can be used to 154 manipulate this per-user data. It is called the Extensible Markup 155 Language (XML) Configuration Access Protocol (XCAP). XCAP is a set 156 of conventions for mapping XML documents and document components into 157 HTTP URLs, rules for how the modification of one resource affects 158 another, data validation constraints, and authorization policies 159 associated with access to those resources. Because of this 160 structure, normal HTTP primitives can be used to manipulate the data. 161 XCAP is based heavily on ideas borrowed from the Application 162 Configuration Access Protocol (ACAP) [24], but it is not an extension 163 of it, nor does it have any dependencies on it. Like ACAP, XCAP is 164 meant to support the configuration needs for a multiplicity of 165 applications, rather than just a single one. 167 2. Overview of Operation 169 Each application that makes use of XCAP specifies an application 170 usage (Section 5). This application usage defines the XML schema [2] 171 for the data used by the application, along with other key pieces of 172 information. The principal task of XCAP is to allow clients to read, 173 write, modify, create and delete pieces of that data. These 174 operations are supported using HTTP 1.1 [5]. An XCAP server acts as 175 a repository for collections of XML documents. There will be 176 documents stored for each application. Within each application, 177 there are documents stored for each user. Each user can have a 178 multiplicity of documents for a particular application. To access 179 some component of one of those documents, XCAP defines an algorithm 180 for constructing a URL that can be used to reference that component. 181 Components refer to any element or attribute within the document. 182 Thus, the HTTP URLs used by XCAP point to a document, or to pieces of 183 information that are finer grained than the XML document itself. An 184 HTTP resource which follows the naming conventions and validation 185 constraints defined here is called an XCAP resource. 187 Since XCAP resources are also HTTP resources, they can be accessed 188 using HTTP methods. Reading an XCAP resource is accomplished with 189 HTTP GET, creating or modifying one is done with HTTP PUT, and 190 removing one of the resources is done with an HTTP DELETE. 191 Properties that HTTP associates with resources, such as entity tags, 192 also apply to XCAP resources. Indeed, entity tags are particularly 193 useful in XCAP, as they allow a number of conditional operations to 194 be performed. 196 3. Terminology 198 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 199 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 200 and "OPTIONAL" are to be interpreted as described in RFC 2119 [6] and 201 indicate requirement levels for compliant implementations. 203 4. Definitions 205 The following terms are used throughout this document: 207 XCAP Resource: An HTTP resource representing an XML document, an 208 element within an XML document, or an attribute of an element 209 within an XML document that follows the naming and validation 210 constraints of XCAP. 212 XCAP Server: An HTTP server that understands how to follow the naming 213 and validation constraints defined in this specification. 215 XCAP Client: An HTTP client that understands how to follow the naming 216 and validation constraints defined in this specification. 218 Application: A collection of software components within a network 219 whose operation depends on data managed and stored on an XCAP 220 server. 222 Application Usage: Detailed information on the interaction of an 223 application with the XCAP server. 225 Application Unique ID (AUID): A unique identifier that differentiates 226 XCAP resources accessed by one application from XCAP resources 227 accessed by another. 229 Naming Conventions: The part of an application usage that specifies 230 well-known URLs used by an application, or more generally, 231 specifies the URLs that are typically accessed by an application 232 during its processing. 234 XCAP User Identifier (XUI): The XUI is a string, valid as a path 235 element in an HTTP URL, that is associated with each user served 236 by the XCAP server. 238 XCAP Root: A context that contains all of the documents across all 239 application usages and users that are managed by the server. 241 Document Selector: A sequence of path segments, with each segment 242 being separated by a "/", that identify the XML document within an 243 XCAP root that is being selected. 245 Node Selector: A sequence of path segments, with each segment being 246 separated by a "/", that identify the XML node (element or 247 attribute) being selected within a document. 249 Path Separator: A single path segment equal to two tilde characters 250 "~~" that is used to separate the document selector from the node 251 selector within an HTTP URL. 253 Document URL: The HTTP URL containing the XCAP root and document 254 selector, resulting in the selection of a specific document. As a 255 result, performing a GET against the document URL would retrieve 256 the document. 258 Node URL: The HTTP URL containing the XCAP root, document selector, 259 path separator and node selector, resulting in the selection of a 260 specific XML node. 262 XCAP Root URL: An HTTP URL that representing the XCAP root. Although 263 a valid URL, the XCAP Root URL does not correspond to an actual 264 resource. 266 Global Tree: A URL that represents the parent for all global 267 documents for a particular application usage within a particular 268 XCAP root. 270 Home Directory: A URL that represents the parent for all documents 271 for a particular user for a particular application usage within a 272 particular XCAP root. 274 Positional Insertion: A PUT operation that results in the insertion 275 of a new element into a document such that its position relative 276 to other children of the same parent is set by the client. 278 5. Application Usages 280 Each XCAP resource on a server is associated with an application. In 281 order for an application to use those resources, application specific 282 conventions must be specified. Those conventions include the XML 283 schema that defines the structure and constraints of the data, well 284 known URLs to bootstrap access to the data, and so on. All of those 285 application specific conventions are defined by the application 286 usage. 288 5.1 Application Unique ID (AUID) 290 Each application usage is associated with a name, called an 291 Application Unique ID (AUID). This name uniquely identifies the 292 application usage, and is different from AUIDs used by other 293 applications. AUIDs exist in one of two namespaces. The first 294 namespace is the IETF namespace. This namespace contains a set of 295 tokens, each of which is registered with IANA. These registrations 296 occur with the publication of standards track RFCs [26] based on the 297 guidelines in Section 14. The second namespace is the 298 vendor-proprietary namespace. Each AUID in that namespace is 299 prefixed with the reverse domain name of the organization creating 300 the AUID, followed by a period, followed by any vendor defined token. 301 As an example, the example.com domain can create an AUID with the 302 value "com.example.foo" but cannot create one with the value 303 "org.example.foo". AUIDs within the vendor namespace do not need to 304 be registered with IANA. The vendor namespace is also meant to be 305 used in lab environments where no central registry is needed. The 306 syntax for AUIDs, expressed in ABNF [11] (and using some of the BNF 307 defined in RFC 2396 [12]) is: 309 AUID = global-auid / vendor-auid 310 global-auid = auid 311 auid = 1*(alphanum / mark) 312 vendor-auid = rev-hostname "." auid 313 rev-hostname = toplabel *( "." domainlabel ) 314 domainlabel = alphanum 315 / alphanum *( alphanum / "-" ) alphanum 317 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 319 5.2 Data Validation 321 One of the responsibilities of an XCAP server is to validate the 322 content of each XCAP resource when an XCAP client tries to modify 323 one. This is done using two mechanisms. Firstly, all application 324 usages MUST describe their document contents using XML schema [2]. 325 The application usage MUST also identify the MIME type for documents 326 compliant to that schema. 328 Unfortunately, XML schemas cannot represent every form of data 329 constraint. As an example, one XML element may contain an integer 330 which defines the maximum number of instances of another element. 331 This constraint cannot be represented with XML schema. However, such 332 constraints may be important to the application usage. The 333 application usage defines any additional constraints beyond those in 334 the schema. 336 Of particular importance are uniqueness constraints. In many cases, 337 an application will require that there only be one instance of some 338 element or attribute within a particular scope. Each uniqueness 339 constraint needs to be specified by identifying the field, or 340 combinations of fields, that need to be unique, and then identifying 341 the scope in which that uniqueness applies. One typical scope is the 342 set of all elements of a certain name within the same parent. 343 Another typical scope is the set of all URLs valid within a 344 particular domain. In some cases these constraints can be specified 345 using XML schema, which provides the element for this 346 purpose. Other uniqueness constraints, such as URL uniqueness across 347 a domain, cannot be expressed by schema. Whether or not the schema 348 is used to express some of the uniqueness requirements, the 349 application usage MUST specify all uniqueness requirements when it 350 defines its data validation needs. 352 For example, the resource lists application usage [21] requires that 353 each element have a unique value for the "name" attribute 354 within a single parent. As another example, the RLS services 355 application usage [21] requires that the value of the "uri" attribute 356 of the element be a URL that is unique within the domain of 357 the URL. 359 Another form of constraint are URL constraints. These are 360 constraints on the scheme or structure of the scheme specific part of 361 the URL. These kinds of constraints cannot be expressed in an XML 362 schema. If these constraints are important to an application usage, 363 they need to be explicitly called out. As an example, the resource 364 lists application usage requires that the URL present in the "uri" 365 attribute of the element be either a SIP or pres URL [22]. 367 Another important data constraint is referential integrity. 368 Referential integrity is important when the name or value of an 369 element or attribute is used as a key to select another element or 370 attribute. An application usage MAY specify referential integrity 371 constraints. However, XCAP servers are not a replacement for 372 Relational Database Management Systems (RDBMS), and therefore servers 373 are never responsible for maintaining referential integrity. XCAP 374 clients are responsible for making all of the appropriate changes to 375 documents in order to maintain referential integrity. 377 The data validation information is consumed by both clients, which 378 use them to make sure they construct requests that will be accepted 379 by the server, and by servers, which validate the constraints when 380 they receive a request (with the exception of referential integrity 381 constraints, which are not validated by the server). 383 5.3 Data Semantics 385 For each application usage, the data present in the XML document has 386 a well defined semantic. The application usage defines that 387 semantic, so that a client can properly construct a document in order 388 to achieve the desired result. They are not used by the server, as 389 it is purposefully unaware of the semantics of the data it is 390 managing. The data semantics are expressed in English prose by the 391 application usage. 393 5.4 Naming Conventions 395 In addition to defining the meaning of the document in the context of 396 a particular application, an application usage has to specify how the 397 applications obtain the documents they need. In particular, it needs 398 to define any well-known URLs used for bootstrapping purposes, and 399 document any other conventions on the URLs used by an application. 400 It should also document how documents reference each other. These 401 conventions are called naming conventions. 403 As an example, the RLS services application usage allows an RLS to 404 obtain the contents of a resource list when the RLS receives a 405 SUBSCRIBE request for a SIP URI identifying an RLS service. The 406 application usage specifies that the list of service definitions is 407 present within a specific document with a specific name within the 408 global tree. This allows the RLS to perform a single XCAP request to 409 fetch the service definition for the service associated with the SIP 410 URI in a SUBSCRIBE request. 412 Naming conventions are used by XCAP clients to construct their URLs. 413 The XCAP server does not make use of them. 415 5.5 Resource Interdependencies 417 When a user modifies an XCAP resource, the content of many other 418 resources is affected. For example, when a user deletes an XML 419 element within a document, it does so by issuing a DELETE request 420 against the URL for the element resource. However, deleting this 421 element also deletes all child elements and their attributes, each of 422 which is also an XCAP resource. As such, manipulation of one 423 resource affects the state of other resources. 425 For the most part, these interdependencies are fully specified by the 426 XML schema used by the application usage. However, in some 427 application usages, there is a need for the server to relate 428 resources together, and such a relationship cannot be specified 429 through a schema. This occurs when changes in one document need to 430 affect another document. Typically, this is the case when an 431 application usage is defining a document that acts as a collection of 432 information defined in other documents. 434 As an example, when a user creates a new RLS service (that is, it 435 creates a new element within an RLS services document), the 436 server adds that element to a read-only global list of services 437 maintained by the server in the global tree. This read-only global 438 list is accessed by the RLS when processing a SIP SUBSCRIBE request. 440 Resource interdependencies are used by both XCAP clients and servers. 442 5.6 Authorization Policies 444 By default, each user is able to access (read, modify, and delete) 445 all of the documents below their home directory, and any user is able 446 to read documents within the global directory. However, only trusted 447 users, explicitly provisioned into the server, can modify global 448 documents. 450 The application usage can specify a different authorization policy 451 that applies to all documents associated with that application usage. 452 An application usage can also specify whether another application 453 usage is used to define the authorization policies. An application 454 usage for setting authorization policies can also be defined 455 subsequent to the definition of the the main application usage. In 456 such a case, the main application usage needs only to specify that 457 such a usage will be defined in the future. 459 If an application usage does not wish to change the default 460 authorization policy, it can merely state that the default policy is 461 used. 463 The authorization policies defined by the application usage are used 464 by the XCAP server during its operation. 466 5.7 Data Extensibility 468 An XCAP server MUST understand an application usage in order to 469 process an HTTP request made against a resource for that particular 470 application usage. However, it is not required for the server to 471 understand all of the contents of a document used by an application 472 usage. A server is required to understand the baseline schema 473 defined by the application usage. However, those schemas can define 474 points of extensibility where new content can be added from other 475 namespaces and corresponding schemas. Sometimes, the server will 476 understand those namespaces and therefore have access to their 477 schemas. Sometimes, it will not. 479 A server MUST allow for documents that contain elements from 480 namespaces not known to the server. In such a case, the server 481 cannot validate that such content is schema compliant; it will only 482 verify that the XML is well-formed. 484 If a client wants to verify that a server supports a particular 485 namespace before operating on a resource, it can query the server for 486 its capabilities using the XCAP Capabilities application usage, 487 discussed in Section 11. 489 5.8 Documenting Application Usages 491 Application usages are documented in specifications which convey the 492 information described above. In particular, an application usage 493 specification MUST provide the following information: 495 o Application Unique ID (AUID): If the application usage is meant 496 for general use on the Internet, the application usage MUST 497 register the AUID into the IETF tree using the IANA procedures 498 defined in Section 14. 500 o XML Schema 502 o MIME Type 504 o Validation Constraints 506 o Data Semantics 507 o Naming Conventions 509 o Resource Interdependencies 511 o Authorization Policies 513 5.9 Guidelines for Creating Application Usages 515 The primary design task when creating a new application usage is to 516 define the schema. Although XCAP can be used with any XML document, 517 intelligent schema design will improve the efficiency and utility of 518 the document when it is manipulated with XCAP. 520 XCAP provides three fundamental ways to select elements amongst a set 521 of siblings - by the name of the element, by its position, or by the 522 value of a specific attribute. Positional selection always allows a 523 client to get exactly what it wants. However, it requires a client 524 to cache a copy of the document in order to construct the predicate. 525 Furthermore, if a client performs a PUT, it requires the client to 526 reconstruct the PUT processing that a server would follow in order to 527 update its local cached copy. Otherwise, the client will be forced 528 to re-GET the document after every PUT, which is inefficient. As 529 such, it is a good idea to design schemas such that common operations 530 can be performed without requiring the client to cache a copy of the 531 document. 533 Without positional selection, a client can pick the element at each 534 step by its name or the value of an attribute. Many schemas include 535 elements that can be repeated within a parent (often, minOccurs 536 equals zero or one, and maxOccurs is unbounded). As such, all of the 537 elements have the same name. This leaves the attribute value as the 538 only way to select an element. Because of this, if an application 539 usage expects user to manipulate elements or attributes that are 540 descendants of an element which can repeat, that element SHOULD 541 include, in its schema, an attribute which can be suitably used as a 542 unique index. Furthermore, the naming conventions defined by that 543 application usage SHOULD specify this uniqueness constraint 544 explicitly. 546 URLs often make a good choice for such unique index. They have 547 fundamental uniqueness properties, and are also usually of semantic 548 significance in the application usage. However, care must be taken 549 when using a URL as an attribute value. URL equality is usually 550 complex. However, attribute equality is performed by the server 551 using XML rules, which are based on case sensitive string comparison. 552 Thus, XCAP will match URLs based on lexical equality, not functional 553 equality. In such cases, an application usage SHOULD consider these 554 implications carefully. 556 XCAP provides the ability of a client to operate on a single element, 557 attribute or document at a time. As a result, it may be possible 558 that common operations the client might perform will require a 559 sequence of multiple requests. This is inefficient, and introduces 560 the possibility of failure conditions when another client modifies 561 the document in the middle of a sequence. In such a case, the client 562 will be forced to detect this case using entity tags (discussed below 563 in Section 7.10), and undo its previous changes. This is very 564 difficult. 566 As a result, the schemas SHOULD be defined so that common operations 567 generally require a single request to perform. Consider an example. 568 Lets say an application usage is defining permissions for users to 569 perform certain operations. The schema can be designed in two ways. 570 The top level of the tree can identify users, and within each user, 571 there can be the permissions associated with the user. In an 572 alternative design, the top level of the tree identifies each 573 permission, and within that permission, the set of users who have it. 574 If, in this application usage, it is common to change the permission 575 for a user from one value to another, the former schema design is 576 better for xcap; it will require a single PUT to make such a change. 577 In the latter case, either the entire document needs to be replaced 578 (which is a single operation), or two PUT operations need to occur - 579 one to remove the user from the old permission, and one to add the 580 user to the new permission. 582 Naming conventions form another key part of the design of an 583 application usage. The application usage should be certain that XCAP 584 clients know where to "start" to retrieve and modify documents of 585 interest. Generally, this will involve the specification of a 586 well-known document at a well-known URL. That document can contain 587 references to other documents that the client needs to read or 588 modify. 590 6. URL Construction 592 In order to manipulate an XCAP resource, the data must be represented 593 by an HTTP URL. XCAP defines a specific naming convention for 594 constructing these URLs. The URL is constructed by concatenating the 595 XCAP root with the document selector with the path separator with a 596 escape coded form of the node selector. The XCAP root is the 597 enclosing context in which all XCAP resources live. The document 598 selector is a path that identifies a document within the XCAP root. 599 The path separator is a path segment with a value of double tilde 600 ("~~"). It is piece of syntactic sugar that separates the document 601 selector from the node selector. The node selector is an expression 602 that identifies an XML element within a document. 604 The sections below describe these components in more detail. 606 6.1 XCAP Root 608 The root of the XCAP hierarchy is called the XCAP root. It defines 609 the context in which all other resources exist. The XCAP root is 610 represented with an HTTP URL, called the XCAP Root URL. This URL is 611 a valid HTTP URL; however, it doesn't point to any resource that 612 actually exists on the server. Its purpose is to identify the root 613 of the tree within the domain where all XCAP documents are stored. 614 It can be any valid HTTP URL, but MUST NOT contain a query string. 615 As an example, http://xcap.example.com/services might be used as the 616 XCAP root URL within the example.com domain. Typically, the XCAP 617 root URL is provisioned into client devices. A server or domain MAY 618 support multiple XCAP root URLs. In such a case, it is effectively 619 operating as if it were serving separate domains. There is never 620 information carryover or interactions between resources in different 621 XCAP root URLs. 623 6.2 Document Selector 625 Each document within the XCAP root is identified by its document 626 selector. The document selector is a sequence of path segments, 627 separated by a slash ("/"). These path segments define a 628 hierarchical structure for organizing documents within any XCAP root. 629 The first path segment MUST be the XCAP AUID. So, continuing the 630 example above, all of the documents used by the resource lists 631 application would be under 632 http://xcap.example.com/services/resource-lists. 634 It is assumed that each application will have data that is set by 635 users, and/or it will have global data that applies to all users. As 636 a result, beneath each AUID there are two sub-trees. One, called 637 "users", holds the documents that are applicable to specific users, 638 and the other, called "global", holds documents applicable to all 639 users. The subtree beneath "global" is called the global tree. The 640 path segment after the AUID MUST either be "global" or "users". 642 Within the "users" tree are zero or more sub-trees, each of which 643 identifies documents that apply to a specific user. Each user known 644 to the server is associated with a username, called the XCAP User 645 Identifier (XUI). This XUI MUST be used as the path segment beneath 646 the "users" segment. The subtree beneath an XUI for a particular 647 user is called their home directory. "User" in this context should 648 be interpreted loosely; a user might correspond to device, for 649 example. 651 XCAP does not itself define what it means for documents to "apply" to 652 a user, beyond specification of a baseline authorization policy, 653 described below in Section 8. Each application usage can specify 654 additional authorization policies which depend on data used by the 655 application itself. 657 The remainder of the document selector (the path following "global" 658 or the XUI) is not constrained by this specification. The 659 application usage MAY introduce constraints, or may allow any 660 structure to be used. 662 The final path segment in the document selector identifies the actual 663 document in the hierarchy. This is equivalent to a filename, except 664 that XCAP does not require that its document resources be stored as 665 files in a file system. However, the term "filename" is used to 666 describe the final path segment in the document selector. In 667 traditional filesystems, the filename would have a filename 668 extension, such as ".xml". There is nothing in this specification 669 that requires or prevents such extensions from being used in the 670 filename. In some cases, the application usage will specify a naming 671 convention for documents, and those naming conventions may or may not 672 specify a file extension. For example, in the RLS services 673 application usage [21], documents in the user's home directory with 674 the filename "index" will be used by the server to compute the global 675 index, which is also a document with the filename "index". 677 When the naming conventions in an application usage do not constrain 678 the filename conventions (or, more generally, the document selector), 679 an application will know the filename (or more generally, the 680 document selector) because it is included as a reference in a 681 document which is at a well known location. As another example, 682 within the index document defined by RLS services, the 683 element has a child element called whose content is a 684 URL pointing to a resource list within the users home directory. 686 As a result, if the user creates a new document, and then references 687 that document from a well-known document (such as the index document 688 above), it doesn't matter whether the user includes an extension in 689 the filename or not, as long as the user is consistent and maintains 690 referential integrity. 692 6.3 Node Selector 694 The node selector specifies specific nodes of the XML document which 695 are to be accessed. A node refers to either an XML element or an 696 attribute of an element. The node selector is an expression which 697 identifies an element or attribute. Its grammar is: 699 node-selector = element-selector ["/" attribute-selector] 700 element-selector = step *( "/" step) 701 step = by-name / by-pos / by-attr / by-pos-attr 702 by-name = NameorAny 703 by-pos = NameorAny "[" position "]" 704 position = 1*DIGIT 705 by-attr = NameorAny "[" "@" att-name "=" <"> 706 att-value <"> "]" 707 by-pos-attr = NameorAny "[" position "]" "[" "@" 708 att-name "=" <"> att-value <"> "]" 709 NameorAny = QName / "*" ; QName from XML Namespaces 710 att-name = QName 711 att-value = AttValue ; from XML specification 712 attribute-selector = "@" att-name 714 The QName grammar is defined in the XML namespaces [3] specification, 715 and the AttValue grammar is defined in the XML specification XML 1.0 716 [1]. 718 Note that the left bracket, right bracket, and double quote 719 characters, which are meaningful to XCAP, cannot be directly 720 represented in the HTTP URL. As a result, they are escape coded when 721 placed within the HTTP URL. 723 Similarly, the XML specification defines the QName production for the 724 grammar for element and attribute names, and the AttValue production 725 for the attribute values. Unfortunately, the characters permitted by 726 these productions include some that are not allowed for pchar, which 727 is the production for the allowed set of characters in path segments 728 in the URL. The AttValue production allows many such characters 729 within the US-ASCII set, including the space. Those characters MUST 730 be escaped coded when placed in the URL. Furthermore, QName and 731 AttValue allow many Unicode characters, outside of US-ASCII. When 732 these characters need to be represented in the HTTP URL, they are 733 escape coded. To do this, the data should be encoded first as octets 734 according to the UTF-8 character encoding [17] and then only those 735 octets that do not correspond to characters in the unreserved set 736 should be percent-encoded. For example, the character A would be 737 represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE 738 would be represented as "%C3%80", and the character KATAKANA LETTER A 739 would be represented as "%E3%82%A2". 741 As a result, the grammar above represents the expressions processed 742 by the XCAP server internally after it has un-escape-coded the URL. 743 The on-the-wire format is dictated by RFC 2396 [12]. In the 744 discussions and examples below, when the node selectors are not part 745 of an HTTP URL, they are presented in their internal format prior to 746 encoding. If an example includes a node selector within an HTTP URL, 747 it is presented in its escape coded form. 749 The node selector is based on the concepts in XPath [9]. Indeed, the 750 node selector expression, before it is escape coded for 751 representation in the HTTP URL, happens to be a valid XPath 752 expression. However, XPath provides a set of functionality far 753 richer than is needed here, and its breadth would introduce much 754 unneeded complexity into XCAP. 756 To determine the XML element or attribute selected by the node 757 selector, processing begins at the root of the XML document. The 758 first step in the element selector is then taken. Each step chooses 759 a single XML element within the current document context. The 760 document context is the point within the XML document from which a 761 specific step is evaluated. The document context begins at the root 762 of the document. When a step determines an element within that 763 context, that element becomes the new context for evaluation of the 764 next step. Each step can select an element by its name, by a 765 combination of name and attribute value, by name and position, or by 766 name, position and attribute. In all cases, the name can be 767 wildcarded, so that all elements get selected. 769 The selection operation operates as follows. Within the current 770 document context, the children of that context are enumerated in 771 document order. If the context is the document, its child is the 772 root element in the document. If the context is an element, its 773 children are all of the children of that element (naturally). Next, 774 those elements whose name is not a match for NameorAny are discarded. 775 An element name is a match if NameorAny is the wildcard, or, if its 776 not a wildcard, the element name matches NameorAny. Matching is 777 discussed below. The result is an ordered list of elements. 779 The elements in the list are further filtered by the predicates, 780 which are the expressions in square brackets following NameorAny. 781 Each predicate further prunes the elements from the current ordered 782 list. These predicates are evaluated in order. If the content of 783 the predicate is a position, the position-th element is selected 784 (that is, treat "position" as a variable, and take the element whose 785 position equals that variable), and all others are discarded. If 786 there are fewer elements in the list than the value of position, the 787 result is a no-match. 789 If the content of the predicate is an attribute name and value, all 790 elements possessing that attribute with that value are selected, and 791 all others are discarded. Note that, although a document can have 792 elements with namespace attributes, those elements cannot be selected 793 using a namespace attribute as a predicate. That is, a step like 794 el-name[@xmlns="namespace"] will never match an element, even if 795 there is an element in the list that specifies a default namespace of 796 "namespace". If there are no elements with attributes having the 797 given name and value, the result is a no-match. 799 After the predicates have been applied, the result will be a 800 no-match, one element, or multiple elements. If the result is 801 multiple elements, the node selector is invalid. Each step in a node 802 selector MUST produce a single element to form the context for the 803 next step. This is more restrictive than general XPath expressions, 804 which allow a context to contain multiple elements. If the result is 805 a no-match, the node selector is invalid. The node selector is only 806 valid if a single element was selected. This element becomes the 807 context for the evaluation of the next step in the node selector 808 expression. 810 Once the last step is executed, if there is no attribute selector, 811 the result of the node selection is the last selected element. If 812 there is an attribute selector, the server checks to see if there is 813 an attribute with that name in the element in the current context. 814 If there is not, the result is considered a no-match. Otherwise, 815 that attribute is selected. Note that namespace attributes (such as 816 xmlns) cannot be selected. 818 As a result, once the entire node selector is evaluated against the 819 document, the result will either be a no-match, invalid, or a single 820 element or single attribute. 822 Matching of element names is performed as follows. The element being 823 compared in the step has its name expanded as described in XML 824 namespaces [3]. The element name in the step is also expanded. This 825 expansion requires that any namespace prefix is converted to its 826 namespace URI. Doing that requires a set of bindings from prefixes 827 to namespace URIs. This set of bindings is equal to the set of 828 bindings in scope for the element being compared to the step. If the 829 element name in the step is not qualified, it is expanded using the 830 default namespace in scope for the element being compared to the 831 step. Comparisons are then performed as described in XML namespaces 832 [3]. Note that the namespace prefix expansions described here are 833 different than those specified in the XPath specification. 835 Matching of attribute names proceeds in a similar way. The attribute 836 in the document has its name expanded as described in XML namespaces 837 [3]. Note that the default namespace for attributes is null. If the 838 attribute name in the attribute selector has a namespace prefix, its 839 name expanded using the namespace bindings in scope for the element 840 in which the attributes appear. If the attribute name in the 841 attribute selector does not have a namespace prefix, the default 842 namespace is null. 844 An implication of these matching rules is that it is impossible to 845 select an element by name when two elements under the same parent use 846 the same namespace prefix and local name, but different namespace 847 URI. For example, in the following document: 849 850 851 852 854 The expression "root/ns:el" is not a valid node selector. It will 855 match both elements. Since a node selector must match only 856 one element, it is invalid. In such a case, positional selections 857 must be used. For example, selecting the second element would be 858 done with the node selector "root/*[2]". 860 Comments, text content, and processing declarations can be present in 861 a document, but cannot be selected by the expressions defined here. 862 This is consistent with the XPath treatment of these components. Of 863 course, if such information is present in a document, and a user 864 selects an XML element enclosing that data, that information would be 865 included in a resulting GET, for example. 867 As an example, consider the following XML document: 869 870 872 874 sip:userA@example.net 878 sip:userB@example.org 882 883 885 Figure 4: Example XML Document 887 The node selector 888 "watcherinfo/watcher-list/watcher[@id="8ajksjda7s"]" would select the 889 following XML element: 891 sip:userA@example.net 895 897 As another example, consider the following document: 899 900 902 903 904 905 906 907 908 910 The node selector "foo/ns1:bar/baz" will select the element in 911 the document. When the step "foo" is evaluated, it is first compared 912 to the element in the document. That element is expanded using 913 the default namespace, "default-namespace". The name "foo" in the 914 step expanded using that same default namespace, and so they match. 915 Similarly, the element matches the step of the same name. 917 The node selector "foo/ns1:bar/ns1:baz" will also select the 918 element. This is because the namespace prefix ns1 is in scope for 919 , and it is bound to "namespace1-uri", which is the namespace 920 associated with the element in the document. 922 7. Client Operations 924 An XCAP client is an HTTP 1.1 compliant client. Specific data 925 manipulation tasks are accomplished by invoking the right set of HTTP 926 methods with the right set of headers on the server. This section 927 describes those in detail. 929 In all cases where the client modifies a document, by deleting or 930 inserting a document, element or attribute resource, the client 931 SHOULD verify that, if the operation were to succeed, the resulting 932 document would meet the data constraints defined by the application 933 usage, including schema validation. For example, if the client 934 performs a PUT operation to 935 http://xcap.example.com/rls-services/users/joe/mybuddies, 936 rls-services is the application unique ID, and the constraints 937 defined by it SHOULD be followed. 939 The client will know what URL to use based on the naming conventions 940 described by the application usage. 942 If the document, after modification, does not meet the data 943 constraints, the server will reject it with a 409. The 409 response 944 may contain an XML body, formatted according to the schema in Section 945 10.2, which provides further information on the nature of the error. 946 The client MAY use this information to try and alter the request so 947 that this time, it might succeed. The client SHOULD NOT simply retry 948 the request without changing some aspect of it. 950 In some cases, the application usage will dictate involve a 951 uniqueness constraint that the client cannot guarantee on its own. 952 One such example is that a URI has to be unique within a domain. 953 Typically, the client is not the owner of the domain, and so it 954 cannot be sure that a URI is unique. In such a case, the client can 955 either generate a sufficiently random identifier, or it can pick a 956 "vanity" identifier in the hopes that it is not taken. In either 957 case, if the identifier is not unique, the server will reject the 958 request with a 409 and suggest alternatives that the client can use 959 to try again. If the server does not suggest alternatives, the 960 client SHOULD attempt to use random identifiers with increasing 961 amounts of randomness. 963 HTTP also specifies that PUT and DELETE requests are idempotent. 964 This means that, if the client performs a PUT on a document and it 965 succeeds, it can perform the same PUT, and the resulting document 966 will look the same. Similarly, when a client performs a DELETE, if 967 it succeeds, a subsequent DELETE to the same URL will generate a 404; 968 the resource no longer exists on the server since it was deleted by 969 the previous DELETE operation. To maintain this property, the client 970 SHOULD construct its URLs such that, after the modification has taken 971 place, the URL in the request will point to the resource just 972 inserted for PUT (i.e., the body of the request), and will point to 973 nothing for DELETE. If this property is maintained, it is the case 974 that GET to the URL in the PUT will return the same content (i.e., 975 GET(PUT(X)) == x). This property implies idempotency. Although a 976 request can still be idempotent if it does not possess this property, 977 XCAP does not permit such requests. If the client's request does not 978 have this property, the server will reject the request with a 409 and 979 indicate a cannot-insert error condition. 981 If the result of the PUT is a 200 or 201 response, the operation was 982 successful. Other response codes to any request, such as a 983 redirection, are processed as per RFC 2616 [5]. 985 7.1 Create or Replace a Document 987 To create or replace a document, the client constructs a URL that 988 references the location where the document is to be placed. This URL 989 MUST be a document URL, and therefore contain the XCAP root and 990 document selector. The client then invokes a PUT method on that URL. 992 The MIME content type MUST be the type defined by the application 993 usage. For example, it would be "application/rls-services+xml" for 994 an RLS services [21] document, and not "application/xml". 996 If the Request-URI identifies a document that already exists in the 997 server, the PUT operation replaces that document with the content of 998 the request. If the Request-URI does not identify an existing 999 document, the document is created on the server at that specific URL. 1001 7.2 Delete a Document 1003 To delete a document, the client constructs a URL that references the 1004 document to be deleted. This URL MUST be a document URL. The client 1005 then invokes a DELETE operation on the URL to delete the document. 1007 7.3 Fetch a Document 1009 As one would expect, fetching a document is trivially accomplished by 1010 performing an HTTP GET request with the Request URI set to the 1011 document URL. 1013 7.4 Create or Replace an Element 1015 To create or replace an XML element within an existing document, the 1016 client constructs a URL whose document selector points to the 1017 document to be modified. The node selector MUST be present in the 1018 URL, separated from the document selector with the path separator. 1019 To create this this element within the document, the node selector is 1020 constructed such that it is a no-match against the current document, 1021 but if the element in the body of the request was added to the 1022 document as desired by the client, the node selector would select 1023 that element. To replace an element in the document, the node 1024 selector is constructed so that it is a match against the element in 1025 the current document to be replaced, as well as a match to the new 1026 element (present in the body of the PUT request) that is to replace 1027 it. 1029 Oftentimes, the client will wish to insert an element into a document 1030 in a certain position relative to other children of the same parent. 1031 This is called a positional insertion. They often arise because the 1032 schema constrains where the element can occur, or because ordering of 1033 elements is significant within the schema. To accomplish this, the 1034 client can use a node selector of the following form: 1036 parent/*[position][unique-attribute-value] 1038 Here, "parent" is an expression for the parent of the element to be 1039 inserted. "position" is the position amongst the existing children 1040 of this parent where the new element is to be inserted. 1041 "unique-attribute-value" is an attribute name and value for the 1042 element to be inserted, which is different from the current element 1043 in "position". The second predicate is needed so that the overall 1044 expression is a no-match when evaluated against the current children. 1045 Otherwise, the PUT would replace the existing element in that 1046 position. 1048 Consider the example document in Figure 4. The client would like to 1049 insert a new element as the second element underneath 1050 . However, it cannot just PUT to a URL with the 1051 watcherinfo/watcher-list/*[2] node selector; this node selector would 1052 select the existing 2nd child of and replace it. 1053 Thus, the PUT has to be made to a URL with 1054 watcherinfo/watcher-list/*[2][@id="hhggff"] as the node selector, 1055 where "hhggff" is the value of the "id" attribute of the new element 1056 to be inserted. This node-selector is a no-match against the current 1057 document, and would be a match against the new element if it was 1058 inserted as the 2nd child of . 1060 The "*" indicates that all children of are to be 1061 considered when computing the position for insertion. If, instead of 1062 a *, an element name was present, the expression above would insert 1063 the new element as the position-th element amongst those with the 1064 same name. 1066 Once the client constructs the URL, it invokes the HTTP PUT method. 1067 If the client is creating a new element, it SHOULD include 1068 "application/xcap-diff+xml" in the Accept header field of the 1069 request. This allows the server to return an XCAP Diff document in a 1070 201 response code, and is useful for subsequent conditional 1071 operations, as described in Section 7.10. The content in the request 1072 MUST be an XML element. Specifically, it contains the element, 1073 starting with the opening bracket for the begin tag for that element, 1074 including the attributes and content of that element (whether it be 1075 text or other child elements), and ending with the closing bracket 1076 for the end tag for that element. The MIME type in the request MUST 1077 be "application/xcap-el+xml", defined in Section 14.2.1. If the node 1078 selector, when evaluated against the current document, results in a 1079 no-match, the server performs a creation operation. If the node 1080 selector, when evaluated against the current document, is a match for 1081 an element in the current document, the server replaces it with the 1082 content of the PUT request. This replacement is complete; that is, 1083 the old element (including its attributes and content) are removed, 1084 and the new one, including its attributes and content, is put in its 1085 place. 1087 To be certain that element insertions have the GET(PUT(x))==x 1088 property, the client can check that the attribute predicates in the 1089 final path segment of the URL match the attributes of the element in 1090 the body of the request. As an example of an request that would not 1091 have this property and therefore not be idempotent, consider the 1092 following PUT request (URLs are line-folded for readability): 1094 PUT 1095 http://xcap.example.com/rls-services/users/bill/index/~~/rls-services/ 1096 service%5b@uri=%22sip:good-friends@example.com%5d 1097 HTTP/1.1 1098 Content-Type:application/xcap-el+xml 1100 1101 http://xcap.example.com/resource-lists/users/joe 1102 /index/~~/resource-lists/list%5b@name=%22l1%22%5d 1103 1104 1105 presence 1106 1107 1109 This request will fail with a 409. The Request URI contains a final 1110 path segment with a predicate based on attributes - 1111 @uri="sip:good-friends@example.com". However, this will not match 1112 the value of the "uri" attribute in the element in the body. 1114 When the client does not explicitly indicate a position in which to 1115 insert a new element, the server will insert that element as the last 1116 child of that parent. If this is not the desired position, the 1117 client should perform a positional insertion. 1119 7.5 Delete an Element 1121 To delete an element from a document, the client constructs a URL 1122 whose document selector points to the document containing the element 1123 to be deleted. The node selector MUST identify a single element. 1124 The node selector MUST be present following the path separator, and 1125 identify the specific element to be deleted. Furthermore, the node 1126 selector MUST match no element after the deletion of the target 1127 element. This is required to maintain the idempotency property of 1128 HTTP deletions. 1130 If the client wishes to delete an element in a specific position, 1131 this is referred to as a positional deletions. Like a positional 1132 insertion, the node selector has the following form: 1134 parent/*[position][unique-attribute-value] 1136 Where "parent" is an expression for the parent of the element to be 1137 deleted, "position" is the position of the element to be deleted 1138 amongst the existing children of this parent, and 1139 "unique-attribute-value" is an attribute name and value for the 1140 element to be deleted, where this attribute name and value are 1141 different than the siblings of the element. 1143 The client then invokes the HTTP DELETE method. If the client plans 1144 on performing conditional operations using If-Match or If-None-Match, 1145 it SHOULD include "application/xcap-diff+xml" in an Accept header 1146 field in the DELETE request. This will allow the server to send an 1147 XCAP Diff document in the response. The server will remove the 1148 element from the document (including its attributes and its content, 1149 such as any children). 1151 7.6 Fetch an Element 1153 To fetch an element of a document, the client constructs a URL whose 1154 document selector points to the document containing the element to be 1155 fetched. The node selector MUST be present following the path 1156 separator, and must identify the element to be fetched. 1158 The client then invokes the GET method. The 200 OK response will 1159 contain that XML element. Specifically, it contains the content of 1160 the XML document, starting with the opening bracket for the begin tag 1161 for that element, and ending with the closing bracket for the end tag 1162 for that element. This will, as a result, include all attributes, 1163 child elements, comments and CDATA of that element. 1165 7.7 Create or Replace an Attribute 1167 To create or replace an attribute in an existing element of a 1168 document, the client constructs a URL whose document selector points 1169 to the document to be modified. The node selector, following the 1170 path separator, MUST be present. The node selector MUST be 1171 constructed such that, if the attribute was created or replaced as 1172 desired, the node selector would select that attribute. If the node 1173 selector, when evaluated against the current document, results in a 1174 no-match, it is a creation operation. If it matches an existing 1175 attribute, it is a replacement operation. 1177 The client then invokes the HTTP PUT method. If the client is 1178 creating a new attribute, it SHOULD include 1179 "application/xcap-diff+xml" in the Accept header field of the 1180 request. This allows the server to return an XCAP Diff document in a 1181 201 response code, and is useful for subsequent conditional 1182 operations, as described in Section 7.10. The content defined by the 1183 request MUST be the value of the attribute, compliant to the grammar 1184 for AttValue as defined in XML 1.0 [1]. Note that, unlike when 1185 AttValue is present in the URL, there is no escape coding. Escaping 1186 only applies to URLs. This request MUST be sent with the 1187 Content-Type of "application/xcap-att+xml" as defined in Section 1188 14.2.2. The server will add that attribute such that, if the node 1189 selector is evaluated on the resulting document, it returns the 1190 attribute present in the request. 1192 To be certain that attribute insertions have the GET(PUT(x))==x 1193 property, the client can check that any attribute predicate in the 1194 path segment that selects the element into which the attribute is 1195 inserted, matches a different attribute than the one being inserted 1196 by the request. As an example of a request that would not have this 1197 property and therefore not be idempotent, consider the following PUT 1198 request (URLs are line folded for readability): 1200 PUT 1201 http://xcap.example.com/rls-services/users/bill/index/~~/ 1202 rls-services/service%5b@uri=%22sip:good-friends@example.com%5d/@uri 1203 HTTP/1.1 1204 Content-Type:application/xcap-att+xml 1206 "sip:bad-friends@example.com" 1208 This request will fail with a 409. 1210 7.8 Delete an Attribute 1212 To delete attributes from the document, the client constructs a URL 1213 whose document selector points to the document containing the 1214 attributes to be deleted. The node selector MUST be present 1215 following the path separator, and evaluate to an attribute in the 1216 document to be deleted. 1218 The client then invokes the HTTP DELETE method. The server will 1219 remove the attribute from the document. 1221 7.9 Fetch an Attribute 1223 To fetch an attribute of a document, the client constructs a URL 1224 whose document selector points to the document containing the 1225 attribute to be fetched. The node selector MUST be present following 1226 the path separator, containing an expression identifying the 1227 attribute whose value is to be fetched. 1229 The client then invokes the GET method. The 200 OK response will 1230 contain an "application/xcap-att+xml" document with the specified 1231 attribute, formatted according to the grammar of AttValue as defined 1232 in the XML 1.0 specifications. 1234 7.10 Conditional Operations 1236 The HTTP specification defines several header fields that can be used 1237 by a client to make the processing of the request conditional. In 1238 particular, the If-None-Match and If-Match header fields allow a 1239 client to make them conditional on the current value of the entity 1240 tag for the resource. These conditional operations are particularly 1241 useful for XCAP resources. 1243 For example, it is anticipated that clients will frequently wish to 1244 cache the current version of a document. So, when the client starts 1245 up, it will fetch the current document from the server and store it. 1246 When it does so, the GET response will contain the entity tag for the 1247 document resource. Each resource within a document maintained by the 1248 server will share the same value of the entity tag. As a result, the 1249 entity tag returned by the server for the document resource is 1250 applicable to element and attribute resources within the document. 1252 If the client wishes to modify an element or attribute within the 1253 document, but it wants to be certain that the document hasn't been 1254 modified since the client last operated on it, it can include an 1255 If-Match header field in the request, containing the value of the 1256 entity tag known to the client for all resources within the document. 1257 If the document has changed, the server will reject this request with 1258 a 412 response. In that case, the client will need to flush its 1259 cached version, fetch the entire document, and store the new entity 1260 tag returned by the server in the 200 OK to the GET request. It can 1261 then retry the request, placing the new entity tag in the If-Match 1262 header field. If this succeeds, the Etag header field in the 1263 response to PUT contains the entity tag for the resource that was 1264 just modified. Because all resources in a document share the same 1265 value for their entity tag, this entity tag value can be applied to 1266 the modification of other resources. 1268 Unfortunately, the same conditional operation cannot be performed for 1269 insertions of elements or attributes. That is, if the client wishes 1270 to insert a new element or attribute into a document, and it wants to 1271 be sure that the document hasn't been modified since the client last 1272 operated on it, it cannot do that. This is because the If-Match 1273 header field applies to the resource in the request URI. For an 1274 insertion, this resource does not yet exist, and the If-Match will 1275 fail. Fortunately, the client can at least detect, after the 1276 insertion is performed, whether or not the document had been modified 1277 prior to the insertion. If the client placed 1278 "application/xcap-diff+xml" into the Accept header field of the 1279 request, the server will return an XCAP diff document to the client, 1280 indicating the entity tags for the entire document (and thus all 1281 resources within it) prior to, and after, the insertion. If the 1282 entity tag prior to the insertion matches the one cached by the 1283 client, the client can know that the document was unmodified prior to 1284 insertion. If the entity tag does not match, the client knows it had 1285 been modified. This specification does not provide a way to tell the 1286 server to roll back. As such, the client can fetch the current 1287 document, or PUT the entire document to the desired value. However, 1288 the best way to handle this case is to avoid it entirely. If a 1289 condition insertion is truly needed (and often they are not), the 1290 client can instead just modify the parent of the element that is to 1291 be inserted, setting it to the current value of that element along 1292 with the newly inserted child. 1294 If the client deletes a resource with DELETE, the resource will no 1295 longer exist, and the HTTP response will not contain an Etag header 1296 field. However, if the client included "application/xcap-diff+xml" 1297 in the Accept header field of its DELETE request, a 200 OK response 1298 will contain an XCAP Diff document, indicating the entity tag for the 1299 document in which the deleted element resided. 1301 The entity tags returned in Etag header fields and XCAP Diff 1302 documents allow the client to track the entity tags for all resources 1303 in a particular document as the client modifies the document. As 1304 long as no other clients try to modify the document, the client will 1305 be able to perform conditional operations on the document without 1306 ever having to perform separate GET operations to synchronize the 1307 document and it's entity tags with the server. 1309 In another example, a client may wish to insert a new element into a 1310 document, but wants to be sure that the insertion will only take 1311 place if that element does not exist. In other words, the client 1312 wants the PUT operation to be a creation, not a replacement. To 1313 accomplish that, the client can insert the If-None-Match header field 1314 into the PUT request, with a value of *. This tells the server to 1315 reject the request with a 412 if resource exists. 1317 As another example, a when a client fetches a document, and there is 1318 an older version cached, it is useful for clients to use a 1319 conditional GET in order to reduce network usage if the cached copy 1320 is still valid. This is done by including, in the GET request, the 1321 If-None-Match header field with a value equal to the current etag 1322 held by the client for the document. The server will only generate a 1323 200 OK reponse if the etag held by the server differs than that held 1324 by the client. If it doesn't differ, the server will respond with a 1325 304 response. 1327 8. Server Behavior 1329 An XCAP server is an HTTP 1.1 compliant origin server. The behaviors 1330 mandated by this specification relate to the way in which the HTTP 1331 URL is interpreted and the content is constructed. 1333 An XCAP server MUST be explicitly aware of the application usage 1334 against which requests are being made. That is, the server must be 1335 explicitly configured to handle URLs for each specific application 1336 usage, and must be aware of the constraints imposed by that 1337 application usage. 1339 When the server receives a request, the treatment depends on the URL. 1340 If the URL refers to an application usage not understood by the 1341 server, the server MUST reject the request with a 404 (Not Found) 1342 response. If the URL refers to a user that is not recognized by the 1343 server, it MUST reject the request with a 404 (Not Found). 1345 Next, the server authenticates the request. All XCAP servers MUST 1346 implement HTTP Digest [10]. Furthermore, servers MUST implement HTTP 1347 over TLS, RFC 2818 [13]. It is RECOMMENDED that administrators use 1348 an HTTPS URL as the XCAP root URL, so that the digest client 1349 authentication occurs over TLS. 1351 Next, the server determines if the client has authorization to 1352 perform the requested operation on the resource. The application 1353 usage defines the authorization policies. An application usage may 1354 specify that the default is used. This default is described in 1355 Section 5.6. 1357 Once authorized, the specific behavior depends on the method and what 1358 the URL refers to. 1360 8.1 POST Handling 1362 XCAP resources do not represent processing scripts. As a result, 1363 POST operations to HTTP URLs representing XCAP resources are not 1364 defined. A server receiving such a request for an XCAP resource 1365 SHOULD return a 405. 1367 8.2 PUT Handling 1369 The behavior of a server in receipt of a PUT request is as specified 1370 in HTTP 1.1 Section 9.6 - the content of the request is placed at the 1371 specified location. This section serves to define the notion of 1372 "placement" and "specified location" within the context of XCAP 1373 resources. 1375 8.2.1 Locating the Parent 1377 The first step the server performs is to locate the parent, whether 1378 it is a directory or element, in which the resource is to be placed. 1379 To do that, the server removes the last path segment from the URL. 1380 The rest of the URL refers to the parent. This parent can be a 1381 document, element, or prefix of a document selector (called a 1382 directory, even though this specification does not mandate that 1383 documents are actually stored in a filesystem). This URL is called 1384 the parent URL. The path segment that was removed is called the 1385 target selector, and the node (element, document or attribute) it 1386 describes is called the target node. 1388 If the parent URL has no path separator, it is referring to the 1389 directory into which the document should be inserted. If this 1390 directory does not exist, the server MUST return a 409 response, and 1391 SHOULD include a detailed conflict report including the 1392 element. Detailed conflict reports are discussed in Section 10. If 1393 the directory does exist, the server checks to see if there is a 1394 document with the same filename as the target node. If there is, the 1395 operation is the replacement operation discussed in Section 8.2.4. 1396 If it does not exist, it is the creation operation, discussed in 1397 Section 8.2.4. 1399 If the parent URL has a path separator, the document selector is 1400 extracted, and that document is retrieved. If the document does not 1401 exist, the server MUST return a 409 response, and SHOULD include a 1402 detailed conflict report including the element. If it 1403 does exist, the node selector is extracted, and unescaped (recall 1404 that the node selector is escape coded). The node selector is 1405 applied to the document based on the matching operations discussed in 1406 Section 6.3. If the result is a no-match or invalid, the server MUST 1407 return a 409 response, and SHOULD include a detailed conflict report 1408 including the element. 1410 If the node-selector is valid, the server examines the target 1411 selector, and evaluates it within the context of the parent node. If 1412 the target node exists within the parent, the operation is a 1413 replacement, as described in Section 8.2.4. If it does not exist, it 1414 is the creation operation, discussed in Section 8.2.4. 1416 Before performing the replacement or creation, as determined based on 1417 the logic above, the server validates the content of the request as 1418 described in Section 8.2.2 1420 8.2.2 Verifying Document Content 1422 If the PUT request is for a document (the request URI had no path 1423 separator), the content of the request body has to be a well-formed 1424 XML document. If it is not, the server MUST reject the request with 1425 a 409 response code. That response SHOULD include a detailed 1426 conflict report including the element. If the MIME 1427 type in the Content-Type header field of the request is not equal to 1428 the MIME type defined for the application usage, the server MUST 1429 reject the request with a 415. 1431 If the PUT request is for an element, the content of the request body 1432 has to be a well-balanced region of an XML document, also known as an 1433 XML fragment body in The XML Fragment Interchange [23] specification, 1434 including only a single element. If it is not, the server MUST 1435 reject the request with a 409 response code. That response SHOULD 1436 include a detailed conflict report including the 1437 element. If the MIME type in the Content-Type header field of the 1438 request is not equal to "application/xcap-el+xml", the server MUST 1439 reject the request with a 415. 1441 If the PUT request is for an attribute, the content of the request 1442 body has to be a sequence of characters that comply with the grammar 1443 for AttValue as defined above. If it is not, the server MUST reject 1444 the request with a 409 response code. That response SHOULD include a 1445 detailed conflict report including the element. 1446 If the MIME type in the Content-Type header field of the request is 1447 not equal to "application/xcap-att+xml", the server MUST reject the 1448 request with a 415. 1450 8.2.3 Creation 1452 The steps in this sub-section are followed if the PUT request will 1453 result in the creation of a new document, element or attribute. 1455 If the PUT request is for a document, the content of the request body 1456 is placed into the directory, and its filename is associated with the 1457 target node, which is a document. 1459 If the PUT request is for an element, the server inserts the content 1460 of the request body as a new child element of the parent element 1461 selected in Section 8.2.1. The insertion is done such that, the 1462 request URI, when evaluated, would now point to the element which was 1463 inserted. If the target selector is defined by a by-name or by-attr 1464 production (in other words, there is no position indicated) the 1465 server MUST insert the element after any other siblings. If a 1466 position is indicated, the server MUST insert the element so that it 1467 is the position-th element amongst all siblings whose name matches 1468 NameorAny. 1470 It is possible that the element cannot be inserted such that the 1471 request URI, when evaluated, returns the content provided in the 1472 request. Such a request is not allowed for PUT. This happens when 1473 the element in the body is not described by the expression in the 1474 target selector. An example of this case is described in Section 1475 7.4. If this happens the server MUST NOT perform the insertion, and 1476 MUST reject the request with a 409 response. The body of the 1477 response SHOULD contain a detailed conflict report containing the 1478 element. It is important to note that schema 1479 compliance does not play a role while performing the insertion. That 1480 is, the decision of where the element gets inserted is dictated 1481 entirely by the structure of the request-URI, the current document, 1482 and the rules in this specification. 1484 If the PUT request is for an attribute, the server inserts the 1485 content of the request body as the value of the attribute. The name 1486 of the attribute is equal to the att-name from the attribute-selector 1487 in the target selector. 1489 Assuming that the insertion can be accomplished, the server verifies 1490 that the insertion results in a document that meets the constraints 1491 of the application usage. This is dicussed in Section 8.2.5. 1493 8.2.4 Replacement 1495 The steps in this sub-section are followed if the PUT request will 1496 result in the replacement of a document, element or attribute with 1497 the contents of the request. 1499 If the PUT request is for a document, the content of the request body 1500 is placed into the directory, replacing the document with the same 1501 filename. 1503 If the PUT request is for an element, the server replaces the target 1504 node with the content of the request body. As in the creation case, 1505 it is possible that, after replacement, the request URI does not 1506 select the element that was just inserted. If this happens the 1507 server MUST NOT perform the replacement, and MUST reject the request 1508 with a 409 response. The body of the response SHOULD contain a 1509 detailed conflict report containing the element. 1511 If the PUT request is for an attribute, the server sets the value of 1512 the selected attribute to the content of the request body. It is 1513 possible in the replacement case (but not in the creation case), 1514 that, after replacement of the attribute, the request URI no longer 1515 selects the attribute that was just replaced. The scenario in which 1516 this can happen is discussed in Section 7.7. If this is the case, 1517 the server MUST NOT perform the replacement, and MUST reject the 1518 request with a 409 response. The body of the response SHOULD contain 1519 a detailed conflict report containing the element. 1521 8.2.5 Validation 1523 Once the document, element or attribute has been tentatively 1524 inserted, the server needs to verify that the resulting document 1525 meets the data constraints outlined by the application usage. 1527 First, the server checks that the final document is compliant to the 1528 schema. If it is not, the server MUST NOT perform the insertion. It 1529 MUST reject the request with a 409 response. That response SHOULD 1530 contain a detailed conflict report containing the 1531 element. 1533 Next, the server checks for any uniqueness constraints identified by 1534 the application usage. If the application usage required that a 1535 particular element or attribute had a unique value within a specific 1536 scope, the server would check that this uniqueness property still 1537 exists. If the application usage required that a URL within the 1538 document was unique within the domain, the server checks whether it 1539 is the case. If any of these uniqueness constraints are not met, the 1540 server MUST NOT perform the insertion. It MUST reject the request 1541 with a 409 response. That response SHOULD contain a detailed 1542 conflict report containing the element. That 1543 element can contain suggested values that the client can retry with. 1544 These SHOULD be values that, at the time the server generates the 1545 409, would meet the uniqueness constraints. 1547 The server also checks for URI constraints and other non-schema data 1548 constraints. If the document fails one of these constraints, the 1549 server MUST NOT perform the insertion. It MUST reject the request 1550 with a 409 response. That response SHOULD contain a detailed 1551 conflict report containing the element. That 1552 element indicates that the document failed non-schema data 1553 constraints explicitly called out by the application usage. 1555 8.2.6 Resource Interdependencies 1557 Because XCAP resources include elements, attributes and documents, 1558 each of which has its own HTTP URL, the creation or modification of 1559 one resource affects the state of many others. For example, 1560 insertion of a document creates resources on the server for all of 1561 the elements and attributes within that document. After the server 1562 has performed the insertion associated with the PUT, the server MUST 1563 create and/or modify those resources affected by that PUT. The 1564 structure of the document completely defines the inter-relationship 1565 between those resources. Normally a server will not need to actually 1566 do anything to meet this requirement, since those other resources 1567 would normally be resolved dynamically when requests are made against 1568 them. 1570 However, the application usage can specify other resource 1571 inter-dependencies. The server MUST create or modify the resources 1572 specified by the application usage. 1574 If the creation or insertion was successful, and the resource 1575 interdependencies are resolved, the server returns a 200 OK or 201 1576 Created, as appropriate. If the client included 1577 "application/xcap-diff+xml" in an Accept header in the PUT request, 1578 and the request was an insertion resulting in a 201 response, the 1579 server SHOULD include an XCAP diff document in the response [4]. The 1580 XCAP diff document SHOULD contain a single element. It 1581 SHOULD indicate the entity tag for the document resource prior to the 1582 insertion in the "previous-etag" attribute, and the entity tag for 1583 the document after insertion in the "new-etag" attribute. A 200 OK 1584 response to PUT MUST not contain any content. 1586 8.3 GET Handling 1588 The semantics of GET are as specified in RFC 2616. This section 1589 clarifies the specific content to be returned for a particular URL 1590 that represents an XCAP resource. 1592 If the request URI contains only a document selector, the server 1593 returns the document specified by the URL if it exists, else returns 1594 a 404 response. The MIME type of the body of the 200 OK response 1595 MUST be the MIME type defined by that application usage (i.e., 1596 "application/resource-lists+xml"). 1598 If the request URI contains a node selector, the server obtains the 1599 document specified by the document selector, and if it is found, 1600 evaluates the node-selector within that document. If no document is 1601 found, or if the node-selector is a no-match or invalid, the server 1602 returns a 404 response. Otherwise, the server returns a 200 OK 1603 response. If the node selector identifies an XML element, that 1604 element is returned in the 200 OK response as an XML fragment body 1605 containing the selected element. The MIME type of the response MUST 1606 be "application/xcap-el+xml". If the node selector identifies an XML 1607 attribute, the value of that attribute is returned in the body of the 1608 response. The MIME type of the response MUST be 1609 "application/xcap-att+xml". 1611 8.4 DELETE Handling 1613 The semantics of DELETE are as specified in RFC 2616. This section 1614 clarifies the specific content to be deleted for a particular URL 1615 that represents an XCAP resource. 1617 If the request URL contains only a document selector, the server 1618 deletes the document specified by the URL if it exists and returns a 1619 200 OK, else returns a 404 response. 1621 If the request URI contains a node selector, the server obtains the 1622 document specified by the document selector, and if it is found, 1623 evaluates the node-selector within that document. If no document is 1624 found, or if the node-selector is a no-match or invalid (note that it 1625 will be invalid if multiple elements or attributes are selected), the 1626 server returns a 404 response. Otherwise, the server removes the 1627 specified element or attribute from the document and performs the 1628 validation checks defined in Section 8.2.5. It is possible that, 1629 after deletion, the request URI selects another element in the 1630 document. If this happens the server MUST NOT perform the deletion, 1631 and MUST reject the request with a 409 response. The body of the 1632 response SHOULD contain a detailed conflict report containing the 1633 element. If the deletion will cause a failure of one 1634 of the constraints, the deletion MUST NOT take place. The server 1635 follows the procedures in Section 8.2.5 for computing the 409 1636 response. If the deletion results in a document that is still valid, 1637 the server MUST perform the deletion, process the resource 1638 interdependencies defined by the application usage, and return a 200 1639 OK response. 1641 Before the server returns the 200 OK response to a DELETE, it MUST 1642 process the resource interdependencies as defined in Section 8.2.6. 1643 Furthermore, if the client included "application/xcap-diff+xml" in an 1644 Accept header in the DELETE request, and the request deleted an 1645 element or attribute in the document, the server SHOULD include an 1646 XCAP diff document in the response [4]. The XCAP diff document 1647 SHOULD contain a single element. It SHOULD indicate the 1648 entity tag for the document resource prior to the deletion in the 1649 "previous-etag" attribute, and the entity tag for the document after 1650 deletion in the "new-etag" attribute. 1652 8.5 Managing Etags 1654 An XCAP server MUST maintain entity tags for all resources that it 1655 maintains. This specification introduces the additional constraint 1656 that when one resource within a document (including the document 1657 itself) changes, that resource is assigned a new etag, and all other 1658 resources within that document MUST be assigned the same etag value. 1659 An XCAP server MUST include the Etag header field in all 200 or 201 1660 responses to PUT, GET, or DELETE [[Todo: Not sure we'll see them in 1661 DELETE responses. Need to check.]]. XCAP resources do not introduce 1662 new requirements on the strength of the entity tags; as in RFC 2616, 1663 weak ones MAY be used if performance constraints or other conditions 1664 make usage of strong ones untenable for some reason. 1666 As a result of this constraint, when a client makes a change to an 1667 element or attribute within a document, the response to that 1668 operation will convey the entity tag of the resource that was just 1669 affected. Since the client knows that this entity tag value is 1670 shared by all of the other resources in the document, the client can 1671 make conditional requests against other resources using that entity 1672 tag. 1674 9. Cache Control 1676 An XCAP resource is a valid HTTP resource, and therefore, it can be 1677 cached by clients and network caches. Network caches, however, will 1678 not be aware of the interdependencies between XCAP resources. As 1679 such, a change to an element in a document by a client will 1680 invalidate other XCAP resources affected by the change. For 1681 application usages contain data that is likely to be dynamic or 1682 written by clients, servers SHOULD set a very short max-age, or else 1683 indicate a no-cache directive. 1685 10. Detailed Conflict Reports 1687 In cases where the server returns a 409 error response, that response 1688 will usually include a document in the body of the response which 1689 provides further details on the nature of the error. This document 1690 is an XML document, formatted according to the schema of Section 1691 10.2. Its MIME type, registered by this specification, is 1692 "application/xcap-error+xml". 1694 10.1 Document Structure 1696 The document structure is simple. It contains the root element 1697 . The content of this element is a specific error 1698 condition. Each error condition is represented by a different 1699 element. This allows for different error conditions to provide 1700 different data about the nature of the error. All error elements 1701 support a "phrase" attribute, which can contain text meant for 1702 rendering to a human user. 1704 The following error elements are defined by this specification: 1706 : This indicates that the body of the request was 1707 not a well-formed XML document. 1709 : This indicates that the request was supposed to 1710 contain a valid XML fragment body, but did not. Most likely this 1711 is because the XML in the body was malformed or not balanced. 1713 : This indicates that an attempt to insert an element, 1714 attribute or document failed because the document or element into 1715 which the insertion was supposed to occur does not exist. This 1716 error element can contain an optional element, which 1717 provides an HTTP URL of the xcap resource that identifies the 1718 closest ancestor element that does exist in the document. Because 1719 this is a valid HTTP URL, its node selector component MUST be 1720 escape encoded. 1722 : This element indicates that the document 1723 was not compliant to the schema after the requested operation was 1724 performed. 1726 : This indicates that the request was supposed to 1727 contain a valid XML attribute value, but did not. 1729 : This indicates that the requested PUT operation 1730 could not be performed because a GET of that resource after the 1731 PUT would not yield the content of the PUT request. 1733 : This indicates that the requested DELETE operation 1734 could not be performed because it would not be idempotent. 1736 : This indicates that the requested operation 1737 would result in a document that did not meet a uniqueness 1738 constraint defined by the application usage. For each URL, 1739 element or attribute specified by the client which is not unique, 1740 an element is present as the content of the error 1741 element. Each element has a "field" attribute that 1742 contains the node selector identifying the XML element or 1743 attribute whose value needs to be unique, but wasn't. Note that 1744 the double quote character, which is allowed in node selectors, 1745 cannot appear within the value of an attribute. As such, it MUST 1746 be represented as ". Beyond that, since the node selector is 1747 not appearing within an HTTP URL, there is no escape encoding. 1749 The element can optionally contain a list of 1750 elements. Each one is a suggested alternate value which does not 1751 currently exist on the server. 1753 : This indicates that the requested operation 1754 would result in a document that failed a data constraint defined 1755 by the application usage, but not enforced by the schema or a 1756 uniqueness constraint. 1758 Extensions to XCAP can define additional error elements. 1760 As an example, the following document indicates that the user 1761 attempted to create an RLS service using the URI 1762 sip:friends@example.com, but that URI already exists: 1764 1765 1766 1767 1768 sip:mybuddies@example.com 1769 1770 1771 1773 10.2 XML Schema 1775 1776 1780 1781 1782 1783 Indicates the reason for the error. 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 This element indicates 1795 that the document was not compliant to the schema after the requested 1796 operation was performed. 1797 1798 1799 1800 1801 1802 1803 1804 This indicates that the request was supposed to 1805 contain a valid XML fragment body, but did not. 1806 1807 1808 1809 1810 1811 1812 1813 This indicates that an attempt to insert 1814 an element, attribute or document failed because the document or 1815 element into which the insertion was 1816 supposed to occur does not exist 1817 1818 1819 1820 1821 1822 Contains an HTTP URI that points to the 1823 element which is the closest ancestor that does exist. 1824 1825 1826 1827 1828 1829 1830 1831 1832 This indicates that the requested 1833 PUT operation could not be performed because a GET of that resource 1834 after the PUT would not yield the content of the PUT request. 1835 1836 1837 1838 1839 1840 1841 1842 1843 This indicates that the 1844 request was supposed to contain a valid XML attribute value, but did 1845 not. 1846 1847 1848 1849 1850 1851 1852 1853 This indicates that the 1854 requested operation would result in a document that did not meet a 1855 uniqueness constraint defined by the application usage. 1856 1857 1858 1859 1860 1861 For each URI, 1862 element or attribute specified by the client which is not unique, 1863 one of these is present. 1864 1865 1866 1867 1868 1869 An optional set of alternate values can be 1870 provided. 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 This indicates that the body of the request was 1884 not a well-formed document. 1885 1886 1887 1888 1889 This indicates that the 1890 requested operation would result in a document that failed a data 1891 constraint defined by the application usage, but not enforced by the 1892 schema or a uniqueness constraint. 1893 1894 1895 1896 1897 This indicates that the requested DELETE 1898 operation could not be performed because it would not be 1899 idempotent. 1900 1901 1902 1904 11. XCAP Server Capabilities 1906 XCAP can be extended through the addition of new application usages 1907 and extensions to the core protocol. An XCAP server can also be 1908 extended to support new namespaces. It will often be necessary for a 1909 client to determine what extensions, application usages or namespaces 1910 a server supports before making a request. To enable that, this 1911 specification defines an application usage with the AUID "xcap-caps". 1912 All XCAP servers MUST support this application usage. This usage 1913 defines a single document within the global tree which lists the 1914 capabilities of the server. Clients can read this well-known 1915 document, and therefore learn the capabilities of the server. 1917 The structure of the document is simple. The root element is 1918 . Its children are , , and 1919 . Each of these contain a list of AUIDs, extensions and 1920 namespaces supported by the server. Extensions are named by tokens 1921 defined by the extension. Namespaces are identified by their 1922 namespace URI. Since all XCAP servers support the "xcap-caps" AUID, 1923 it MUST be listed in the element. 1925 The following sections provide the information needed to define this 1926 application usage. 1928 11.1 Application Usage ID (AUID) 1930 This specification defines the "xcap-caps" AUID within the IETF tree, 1931 via the IANA registration in Section 14. 1933 11.2 XML Schema 1935 1936 1941 1942 1943 Root element for xcap-caps 1944 1945 1946 1947 1948 1949 List of supported AUID. 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 List of supported extensions. 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 List of supported namespaces. 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 AUID Type 1985 1986 1987 1988 1989 1990 Extension Type 1991 1992 1993 1994 1995 1996 Namespace type 1997 1998 1999 2000 2002 11.3 MIME Type 2004 Documents conformant to this schema are known by the MIME type 2005 "application/xcap-caps+xml", registered in Section 14.2.4. 2007 11.4 Validation Constraints 2009 There are no additional validation constraints associated with this 2010 application usage. 2012 11.5 Data Semantics 2014 Data semantics are defined above. 2016 11.6 Naming Conventions 2018 A server MUST maintain a single instance of the document in the 2019 global tree, using the filename "index". There MUST NOT be an 2020 instance of this document in the users tree. 2022 11.7 Resource Interdependencies 2024 There are no resource interdependencies in this application usage 2025 beyond those defined by the schema. 2027 11.8 Authorization Policies 2029 This application usage does not change the default authorization 2030 policy defined by XCAP. 2032 12. Examples 2034 This section goes through several examples, making use of the 2035 resource-lists and rls-services [21] XCAP application usages. 2037 First, a user Bill creates a new document (see Section 7.1). This 2038 document is a new resource-list, initially with a single list, called 2039 friends, with no users in it: 2041 PUT 2042 http://xcap.example.com/services/resource-lists/users/bill/fr.xml HTTP/1.1 2043 Content-Type:application/resource-lists+xml 2045 2046 2047 2048 2049 2051 Next, Bill creates an RLS services document defining a single RLS 2052 service referencing this list. This service has a URI of 2053 sip:myfriends@example.com (URIs are line-folded for readability): 2055 PUT 2056 http://xcap.example.com/services/rls-services/users/bill/index HTTP/1.1 2057 Content-Type:application/rls-services+xml 2059 2060 2062 2063 http://xcap.example.com/services/resource-lists/users/bill/ 2064 fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d 2065 2066 2067 presence 2068 2069 2070 2072 Next, Bill creates an element in the resource-lists document (Section 2073 7.4). In particular, he adds an entry to the list: 2075 PUT 2076 http://xcap.example.com/services/resource-lists/users/bill/fr.xml 2077 /~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1 2078 Content-Type:application/xcap-el+xml 2080 2081 Bob Jones 2082 2084 Next, Bill fetches the document (Section 7.3): 2086 GET 2087 http://xcap.example.com/services/resource-lists/users/bill/fr.xml HTTP/1.1 2089 And the result is: 2091 HTTP/1.1 200 OK 2092 Etag: "wwhha" 2093 Content-Type: application/resource-lists+xml 2095 2096 2098 2099 2100 Bob Jones 2101 2102 2103 2105 Next, Bill adds another entry to the list, which is another list that 2106 has three entries. This is another element creation (Section 7.4): 2108 PUT 2109 http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ 2110 resource-lists/list%5b@name=%22friends%22%5d/ 2111 list%5b@name=%22close-friends%22%5d HTTP/1.1 2112 Content-Type: application/xcap-el+xml 2114 2115 2116 Joe Smith 2117 2118 2119 Nancy Gross 2120 2121 2122 Petri Aukia 2123 2124 2126 Then, Bill decides he doesnt want Petri on the list, so he deletes 2127 the entry (Section 7.5): 2129 DELETE 2130 http://xcap.example.com/services/resource-lists/users/bill/fr.xml/ 2131 ~~/resource-lists/list/list/ 2132 entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1 2134 Bill decides to check on the URI for Nancy, so he fetches a 2135 particular attribute (Section 7.6): 2137 GET 2138 http://xcap.example.com/services/resource-lists/users/bill/fr.xml/ 2139 ~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1 2141 and the server responds: 2143 HTTP/1.1 200 OK 2144 Etag: "ad88" 2145 Content-Type:application/xcap-att+xml 2147 "sip:nancy@example.com" 2149 13. Security Considerations 2151 Frequently, the data manipulated by XCAP contains sensitive 2152 information. To avoid eavesdroppers from seeing this information, it 2153 is RECOMMENDED that an admistrator hand out an https URL as the XCAP 2154 root URL. This will result in TLS-encrypted communications between 2155 the client and server, preventing any eavesdropping. 2157 Client and server authentication are also important. A client needs 2158 to be sure it is talking to the server it believes it is contacting. 2159 Otherwise, it may be given false information, which can lead to 2160 denial of service attacks against a client. To prevent this, a 2161 client SHOULD attempt to upgrade [14] any connections to TLS. 2162 Similarly, authorization of read and write operations against the 2163 data is important, and this requires client authentication. As a 2164 result, a server SHOULD challenge a client using HTTP Digest [10] to 2165 establish its identity, and this SHOULD be done over a TLS 2166 connection. 2168 14. IANA Considerations 2170 There are several IANA considerations associated with this 2171 specification. 2173 14.1 XCAP Application Usage IDs 2175 This specification instructs IANA to create a new registry for XCAP 2176 application usage IDs (AUIDs). This registry is defined as a table 2177 that contains three colums: 2179 AUID: This will be a string provided in the IANA registrations into 2180 the registry. 2182 Description: This is text that is supplied by the IANA registration 2183 into the registry. 2185 Document: This is a reference to the RFC containing the registration. 2187 This specification instructs IANA to create this table with an 2188 initial entry. The resulting table would look like: 2190 Application Unique Description Document 2191 ID (AUID) 2192 ----------------------------------------------------------- 2194 xcap-caps Capabilities of an RFC XXXX 2195 XCAP server 2197 [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of 2198 this specification.]] 2199 XCAP AUIDs are registered by the IANA when they are published in 2200 standards track RFCs. The IANA Considerations section of the RFC 2201 must include the following information, which appears in the IANA 2202 registry along with the RFC number of the publication. 2204 Name of the AUID. The name MAY be of any length, but SHOULD be no 2205 more than twenty characters long. The name MUST consist of 2206 alphanum and mark [15] characters only. 2208 Descriptive text that describes the application usage. 2210 14.2 MIME Types 2212 This specification requests the registration of several new MIME 2213 types according to the procedures of RFC 2048 [7] and guidelines in 2214 RFC 3023 [8]. 2216 14.2.1 application/xcap-el+xml MIME Type 2218 MIME media type name: application 2220 MIME subtype name: xcap-el+xml 2222 Mandatory parameters: none 2224 Optional parameters: Same as charset parameter application/xml as 2225 specified in RFC 3023 [8]. 2227 Encoding considerations: Same as encoding considerations of 2228 application/xml as specified in RFC 3023 [8]. 2230 Security considerations: See Section 10 of RFC 3023 [8]. 2232 Interoperability considerations: none. 2234 Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please 2235 replace XXXX with the published RFC number of this 2236 specification.]]. 2238 Applications which use this media type: This document type has been 2239 used to support transport of XML fragment bodies in RFC XXXX 2240 [[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC 2241 number of this specification.]], the XML Configuration Access 2242 Protocol (XCAP). 2244 Additional Information: 2246 Magic Number: None 2248 File Extension: .xel or .xml 2250 Macintosh file type code: "TEXT" 2252 Personal and email address for further information: Jonathan 2253 Rosenberg, jdrosen@jdrosen.net 2255 Intended usage: COMMON 2257 Author/Change controller: The IETF. 2259 14.2.2 application/xcap-att+xml MIME Type 2261 MIME media type name: application 2263 MIME subtype name: xcap-att+xml 2265 Mandatory parameters: none 2267 Optional parameters: Same as charset parameter application/xml as 2268 specified in RFC 3023 [8]. 2270 Encoding considerations: Same as encoding considerations of 2271 application/xml as specified in RFC 3023 [8]. 2273 Security considerations: See Section 10 of RFC 3023 [8]. 2275 Interoperability considerations: none. 2277 Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please 2278 replace XXXX with the published RFC number of this 2279 specification.]]. 2281 Applications which use this media type: This document type has been 2282 used to support transport of XML attribute values in RFC XXXX 2283 [[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC 2284 number of this specification.]], the XML Configuration Access 2285 Protocol (XCAP). 2287 Additional Information: 2289 Magic Number: None 2291 File Extension: .xav 2293 Macintosh file type code: "TEXT" 2295 Personal and email address for further information: Jonathan 2296 Rosenberg, jdrosen@jdrosen.net 2298 Intended usage: COMMON 2300 Author/Change controller: The IETF. 2302 14.2.3 application/xcap-error+xml MIME Type 2304 MIME media type name: application 2306 MIME subtype name: xcap-error+xml 2308 Mandatory parameters: none 2310 Optional parameters: Same as charset parameter application/xml as 2311 specified in RFC 3023 [8]. 2313 Encoding considerations: Same as encoding considerations of 2314 application/xml as specified in RFC 3023 [8]. 2316 Security considerations: See Section 10 of RFC 3023 [8]. 2318 Interoperability considerations: none. 2320 Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please 2321 replace XXXX with the published RFC number of this 2322 specification.]]. 2324 Applications which use this media type: This document type conveys 2325 error conditions defined in RFC XXXX. [[NOTE TO RFC EDITOR: 2326 Please replace XXXX with the published RFC number of this 2327 specification.]] 2329 Additional Information: 2331 Magic Number: None 2333 File Extension: .xer 2334 Macintosh file type code: "TEXT" 2336 Personal and email address for further information: Jonathan 2337 Rosenberg, jdrosen@jdrosen.net 2339 Intended usage: COMMON 2341 Author/Change controller: The IETF. 2343 14.2.4 application/xcap-caps+xml MIME Type 2345 MIME media type name: application 2347 MIME subtype name: xcap-caps+xml 2349 Mandatory parameters: none 2351 Optional parameters: Same as charset parameter application/xml as 2352 specified in RFC 3023 [8]. 2354 Encoding considerations: Same as encoding considerations of 2355 application/xml as specified in RFC 3023 [8]. 2357 Security considerations: See Section 10 of RFC 3023 [8]. 2359 Interoperability considerations: none. 2361 Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please 2362 replace XXXX with the published RFC number of this 2363 specification.]]. 2365 Applications which use this media type: This document type conveys 2366 capabililites of an XML Configuration Access Protocol (XCAP) 2367 server, as defined in RFC XXXX. [[NOTE TO RFC EDITOR: Please 2368 replace XXXX with the published RFC number of this 2369 specification.]] 2371 Additional Information: 2373 Magic Number: None 2375 File Extension: .xca 2377 Macintosh file type code: "TEXT" 2378 Personal and email address for further information: Jonathan 2379 Rosenberg, jdrosen@jdrosen.net 2381 Intended usage: COMMON 2383 Author/Change controller: The IETF. 2385 14.3 URN Sub-Namespace Registrations 2387 This specification registers several new XML namespaces, as per the 2388 guidelines in RFC 3688 [16]. 2390 14.3.1 urn:ietf:params:xml:ns:xcap-error 2392 URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error 2394 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 2395 Jonathan Rosenberg (jdrosen@jdrosen.net). 2397 XML: 2399 BEGIN 2400 2401 2403 2404 2405 2407 XCAP Error Namespace 2408 2409 2410

Namespace for XCAP Error Documents

2411

urn:ietf:params:xml:ns:xcap-error

2412

See RFCXXXX [[NOTE 2413 TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 2414 this specification]].

2415 2416 2417 END 2419 14.3.2 urn:ietf:params:xml:ns:xcap-caps 2420 URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps 2422 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 2423 Jonathan Rosenberg (jdrosen@jdrosen.net). 2425 XML: 2427 BEGIN 2428 2429 2431 2432 2433 2435 XCAP Capabilities Namespace 2436 2437 2438

Namespace for XCAP Capability Documents

2439

urn:ietf:params:xml:ns:xcap-caps

2440

See RFCXXXX [[NOTE 2441 TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 2442 this specification]].

2443 2444 2445 END 2447 14.4 XML Schema Registrations 2449 This section registers two XML schemas per the procedures in [16]. 2451 14.4.1 XCAP Error Schema Registration 2453 URI: urn:ietf:params:xml:schema:xcap-error 2455 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 2456 Jonathan Rosenberg (jdrosen@jdrosen.net). 2458 XML Schema: The XML for this schema can be found as the sole content 2459 of Section 10.2. 2461 14.4.2 XCAP Capabilities Schema Registration 2462 URI: urn:ietf:params:xml:schema:xcap-caps 2464 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 2465 Jonathan Rosenberg (jdrosen@jdrosen.net). 2467 XML Schema: The XML for this schema can be found as the sole content 2468 of Section 11.2. 2470 15. Acknowledgements 2472 The author would like to thank Ben Campbell, Eva-Maria Leppanen, 2473 Hisham Khartabil, Chris Newman, Joel Halpern, Jari Urpalainen, and 2474 Lisa Dusseault for their input and comments. A special thanks to Ted 2475 Hardie for his input and support. 2477 16. References 2479 16.1 Normative References 2481 [1] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C. and E. 2482 Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", 2483 W3C REC REC-xml-20040204, February 2004. 2485 [2] Maloney, M., Beech, D., Mendelsohn, N. and H. Thompson, "XML 2486 Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, 2487 May 2001. 2489 [3] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 2490 REC REC-xml-names-19990114, January 1999. 2492 [4] Rosenberg, J., "An Extensible Markup Language (XML) Document 2493 Format for Indicating Changes in XML Configuration Access 2494 Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02 2495 (work in progress), July 2004. 2497 [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2498 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2499 HTTP/1.1", RFC 2616, June 1999. 2501 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2502 Levels", BCP 14, RFC 2119, March 1997. 2504 [7] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 2505 Mail Extensions (MIME) Part Four: Registration Procedures", BCP 2506 13, RFC 2048, November 1996. 2508 [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 2509 3023, January 2001. 2511 [9] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 2512 1.0", W3C REC REC-xpath-19991116, November 1999. 2514 [10] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2515 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 2516 Basic and Digest Access Authentication", RFC 2617, June 1999. 2518 [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2519 Specifications: ABNF", RFC 2234, November 1997. 2521 [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2522 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2523 1998. 2525 [13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2527 [14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 2528 RFC 2817, May 2000. 2530 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2531 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2532 Session Initiation Protocol", RFC 3261, June 2002. 2534 [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2535 January 2004. 2537 [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 2538 63, RFC 3629, November 2003. 2540 16.2 Informative References 2542 [18] Rosenberg, J., "A Presence Event Package for the Session 2543 Initiation Protocol (SIP)", RFC 3856, August 2004. 2545 [19] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 2546 Protocol (SIP) Event Notification Extension for Resource 2547 Lists", draft-ietf-simple-event-list-05 (work in progress), 2548 August 2004. 2550 [20] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of 2551 Data Elements in Session Initiation Protocol (SIP) for Instant 2552 Messaging and Presence Leveraging Extensions (SIMPLE) Systems", 2553 draft-ietf-simple-data-req-03 (work in progress), June 2003. 2555 [21] Rosenberg, J., "Extensible Markup Language (XML) Formats for 2556 Representing Resource Lists", 2557 draft-ietf-simple-xcap-list-usage-03 (work in progress), July 2558 2004. 2560 [22] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 2561 August 2004. 2563 [23] Grosso, P. and D. Veillard, "XML Fragment Interchange", W3C CR 2564 CR-xml-fragment-20010212, February 2001. 2566 [24] Newman, C. and J. Myers, "ACAP -- Application Configuration 2567 Access Protocol", RFC 2244, November 1997. 2569 [25] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 2570 Instant Messaging", RFC 2778, February 2000. 2572 [26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2573 Considerations Section in RFCs", BCP 26, RFC 2434, October 2574 1998. 2576 [27] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2577 Notification", RFC 3265, June 2002. 2579 Author's Address 2581 Jonathan Rosenberg 2582 Cisco Systems 2583 600 Lanidex Plaza 2584 Parsippany, NJ 07054 2585 US 2587 Phone: +1 973 952-5000 2588 EMail: jdrosen@dynamicsoft.com 2589 URI: http://www.jdrosen.net 2591 Intellectual Property Statement 2593 The IETF takes no position regarding the validity or scope of any 2594 Intellectual Property Rights or other rights that might be claimed to 2595 pertain to the implementation or use of the technology described in 2596 this document or the extent to which any license under such rights 2597 might or might not be available; nor does it represent that it has 2598 made any independent effort to identify any such rights. Information 2599 on the procedures with respect to rights in RFC documents can be 2600 found in BCP 78 and BCP 79. 2602 Copies of IPR disclosures made to the IETF Secretariat and any 2603 assurances of licenses to be made available, or the result of an 2604 attempt made to obtain a general license or permission for the use of 2605 such proprietary rights by implementers or users of this 2606 specification can be obtained from the IETF on-line IPR repository at 2607 http://www.ietf.org/ipr. 2609 The IETF invites any interested party to bring to its attention any 2610 copyrights, patents or patent applications, or other proprietary 2611 rights that may cover technology that may be required to implement 2612 this standard. Please address the information to the IETF at 2613 ietf-ipr@ietf.org. 2615 Disclaimer of Validity 2617 This document and the information contained herein are provided on an 2618 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2619 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2620 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2621 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2622 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2623 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2625 Copyright Statement 2627 Copyright (C) The Internet Society (2004). This document is subject 2628 to the rights, licenses and restrictions contained in BCP 78, and 2629 except as set forth therein, the authors retain all their rights. 2631 Acknowledgment 2633 Funding for the RFC Editor function is currently provided by the 2634 Internet Society.