idnits 2.17.00 (12 Aug 2021) /tmp/idnits10861/draft-ietf-simple-common-policy-caps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 536. ** 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. 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 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 138 has weird spacing: '...mations suppo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2005) is 6158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 494, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '3') == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == Outdated reference: draft-ietf-geopriv-common-policy has been published as RFC 4745 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2048 (ref. '8') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 3023 (ref. '9') (Obsoleted by RFC 7303) == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: January 11, 2006 July 10, 2005 6 An Extensible Markup Language (XML) Representation for Expressing Policy 7 Capabilities 8 draft-ietf-simple-common-policy-caps-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 11, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 An important component of presence and location services is policy. 42 Policy systems allow the presentity or location target to grant 43 access to specific pieces of information to specific watchers or 44 requestors. These policy systems can be extremely simple, allowing a 45 user to accept or block requests based solely on the identity of the 46 requestor, to extremely complex, allowing for time based rules that 47 grant or deny specific pieces of information. Policy systems often 48 support vendor proprietary features. To allow for interoperability 49 between clients which set such policies, and servers which execute 50 them, it is necessary for clients to be able to determine the 51 capabilities of the server to which it is connected. This 52 specification defines an Extensible Markup Language (XML) based 53 format for expressing such capabilities. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 3 60 4. Structure of Policy Capabilities . . . . . . . . . . . . . . 4 61 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Example Document . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1 Application Unique ID . . . . . . . . . . . . . . . . . . 7 65 7.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.3 Default Namespace . . . . . . . . . . . . . . . . . . . . 8 67 7.4 MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.5 Validation Constraints . . . . . . . . . . . . . . . . . . 8 69 7.6 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 8 70 7.7 Naming Conventions . . . . . . . . . . . . . . . . . . . . 8 71 7.8 Resource Interdependencies . . . . . . . . . . . . . . . . 8 72 7.9 Authorization Policies . . . . . . . . . . . . . . . . . . 8 73 8. Security Considerations . . . . . . . . . . . . . . . . . . 9 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 75 9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 9 76 9.2 MIME Type Registration . . . . . . . . . . . . . . . . . . 9 77 9.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 10 78 9.4 XML Schema Registration . . . . . . . . . . . . . . . . . 11 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 10.1 Normative References . . . . . . . . . . . . . . . . . . 11 81 10.2 Informative References . . . . . . . . . . . . . . . . . 12 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property and Copyright Statements . . . . . . . 14 85 1. Terminology 87 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 88 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 89 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 90 indicate requirement levels for compliant implementations. 92 2. Introduction 94 An important component of presence [10] and location services [11] is 95 policy. Policy systems allow the presentity or location target 96 (referred to generically as the Presentity Target (PT)) to grant 97 access to specific pieces of information to specific watchers or 98 requestors (referred to as a WR) [5]. These policy systems can be 99 extremely simple, allowing a PT to accept or block requests based 100 solely on the identity of the WR, to extremely complex, allowing for 101 time based rules that grant or deny specific pieces of information. 102 [5] specifies a generic format for representing these policies, using 103 the Extensible Markup Language (XML). These policies consist of 104 conditions, actions, and transformations. That specification defines 105 very few actual conditions, actions or transformations. Rather, it 106 leaves such definitions to actual policy systems, such as [5] for 107 location services, and [13] for presence services. 109 In addition to the conditions, actions and transformations specificed 110 in the documents referenced above, policy systems often support 111 vendor proprietary features. It is also anticipated that future 112 specifications will be continually developed that add new types of 113 policies. This presents an interoperability challenge. Clients may 114 support policies that are not supported by the servers they are 115 using. This could lead to protocol failures or poor user 116 experiences. 118 To address this problem, it is necessary for a capability declaration 119 system to be put in place. This specification defines a general 120 purpose format for representing policy capabilities within the 121 framework established in [5]. 123 3. Overview of Operation 125 This specification defines an XML-based document format that allows a 126 server to represent its capabilities. When a client, acting as an 127 agent of a PT, starts up, it obtains this document from its policy 128 server. This specification does not prescribe a singular means of 129 transporting such a document between the server and the client. It 130 is anticipated that different systems may use different techniques. 131 However, for systems that make use of the XML Configuration Access 132 Protocol (XCAP) [4], Section 7 defines an application usage that 133 allows for the transfer of the document using XCAP. 135 Once the document has been obtained by the client, it can determine 136 which actions, conditions and transformations are understood by the 137 server. This set is matched against those supported by the client. 138 Those actions, conditions and transformations supported by the 139 client, but not by the server, can be "greyed out" from a user 140 interface, for example. 142 It is anticipated that the capabilities of the server can change over 143 time. As a result, it is RECOMMENDED that clients obtain a fresh 144 copy of the capabilities document each time they start. 146 4. Structure of Policy Capabilities 148 A policy capabilities document is an XML [6] document that MUST be 149 well-formed and SHOULD be valid. Policy capabilities documents MUST 150 be based on XML 1.0 and MUST be encoded using UTF-8. This 151 specification makes use of XML namespaces for identifying policy 152 capabilities documents and document fragments. The namespace URI for 153 elements defined for this purpose is a URN [2], using the namespace 154 identifier 'ietf' defined by [3] and extended by [7]. This URN is: 156 urn:ietf:params:xml:ns:policy-capabilities 158 A policy capabilities document is structured much like a policy 159 document [5]. The root element is . This 160 element has three children - , , and 161 . Each of these contain a list of the condition, 162 action, and transformation capabilities, respectively. Generally 163 speaking, each specific condition, action or transformation element 164 (referred to as a capability element) is empty, unless it requires 165 additional content to further refine the capability. 167 This specification defines three capability elements - , 168 , and matching the three conditions defined in 169 [5]. Other specifications that define additional policies MUST also 170 define matching capability elements. When such elements are defined, 171 that specification MUST indicate, for each capability element, the 172 corresponding action, condition, or permission elements which can be 173 placed into a common policy document [5]. The name of the capability 174 element need not match the name of the corresponding condition, 175 action or transformation, although using a matching name is 176 RECOMMENDED. 178 A server constructing a document to represent its capabilities MUST 179 include all of its capabilities, even if those capabilities represent 180 mandatory-to-implement features. However, the server MAY indicate 181 differing sets of capabilities to different users. As such, the set 182 of capabilities combines both the ability and the willingness to 183 support those capabilities. 185 5. XML Schema 187 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 232 6. Example Document 234 The following document indicates that the identity, validity and 235 sphere conditions are supported. It also indicates that a vendor- 236 specific capability, called , is supported, a vendor specific 237 action capability, , is supported, and a vendor-specific 238 transformation capability - is supported. The 239 specification which defines these capabilities would indicate the 240 specific elements which could be included in a policy document. 242 243 248 249 250 251 252 253 254 255 256 257 258 259 260 262 7. Usage with XCAP 264 The following section defines the details necessary for clients to 265 read supported permissions documents from a server using XCAP. 267 7.1 Application Unique ID 269 XCAP requires application usages to define an application unique ID 270 (AUID) in either the IETF tree or a vendor tree. This specification 271 defines the "policy-capabilities" AUID within the IETF tree, via the 272 IANA registration in Section 9. 274 7.2 XML Schema 276 The schema is defined in Section 5. 278 7.3 Default Namespace 280 The default namespace used in evaluating a URI is 281 urn:ietf:params:xml:ns:policy-capabilities. 283 7.4 MIME Type 285 The MIME type for this document is "application/policy-caps+xml". 287 7.5 Validation Constraints 289 This specification does not introduce any additional validation 290 constraints beyond those defined in the schema. 292 7.6 Data Semantics 294 Semantics for the document content are provided in Section 4. 296 7.7 Naming Conventions 298 When a client starts, it can fetch the capabilities of the server in 299 one of two places. If the server capabilities differ on a user by 300 user basis, the capabilities for user foo can be found in the 301 document with filename "cap.xml" in the user's home directory for 302 this application usage. A client SHOULD check this file first. If 303 this document doesn't exist, the client should next check for the 304 system wide permissions by reading the document with filename 305 "cap.xml" in the global directory for this application usage. 307 7.8 Resource Interdependencies 309 Policy capability documents are usually either created automatically 310 by the server, or modified by administrator to reflect the features 311 of a server. For those users that have access to the full 312 capabilities of the server, a change in the server-wide capabilities, 313 expressed in the "cap.xml" file in the global directory, MUST be 314 reflected in any "cap.xml" documents in user's home directories. 316 7.9 Authorization Policies 318 This application usage does not use the default XCAP authorization 319 policies. 321 A user cannot modify the supported permissions document, they can 322 only read it. Write access is granted only to administrators. 324 A user can read the "cap.xml" document in the global directory, but 325 cannot modify it. Write access is granted only to administrators. 327 8. Security Considerations 329 Policy capability documents reveal capability information about a 330 server. This information can potentially be used by an enterprise to 331 determine the features found in competitive products. However, such 332 information could just as easily be obtained through other means, for 333 example, by signing up as a legitimate user of the competitive 334 service. Because supported permission documents can vary by user to 335 user, they can also reveal information about the grade of service 336 offered to a particular user. However, this information does not 337 appear particularly sensitive. As a result, encryption of these 338 documents is not terribly important. 340 If an attacker can modify the contents of a supported permission 341 document as it passes from client to server, the attacker can remove 342 capability elements, therefore reducing the level of service received 343 by the client. This can therefore form a type of denial-of-service 344 attack. As a result, systems which transfer these documents SHOULD 345 provide for message integrity. 347 9. IANA Considerations 349 There are several IANA considerations associated with this 350 specification. 352 9.1 XCAP Application Usage ID 354 This section registers an XCAP Application Unique ID (AUID) according 355 to the IANA procedures defined in [4]. 357 Name of the AUID: policy-capabilities 359 Description: Policy capability documents describe the capabilities 360 of a policy server to support different conditions, actions, and 361 transformations, as defined in [5]. 363 9.2 MIME Type Registration 365 This specification requests the registration of a new MIME type 366 according to the procedures of RFC 2048 [8] and guidelines in RFC 367 3023 [9]. 369 MIME media type name: application 370 MIME subtype name: policy-caps+xml 372 Mandatory parameters: none 374 Optional parameters: Same as charset parameter application/xml as 375 specified in RFC 3023 [9]. 377 Encoding considerations: Same as encoding considerations of 378 application/xml as specified in RFC 3023 [9]. 380 Security considerations: See Section 10 of RFC 3023 [9] and 381 Section 8 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 382 XXXX with the RFC number of this specification]]. 384 Interoperability considerations: none. 386 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 387 Please replace XXXX with the RFC number of this specification]] 389 Applications which use this media type: This document type has 390 been used to support capabilities for presence and geolocation. 392 Additional Information: 394 Magic Number: None 396 File Extension: .pcp 398 Macintosh file type code: "TEXT" 400 Personal and email address for further information: Jonathan 401 Rosenberg, jdrosen@jdrosen.net 403 Intended usage: COMMON 405 Author/Change controller: The IETF. 407 9.3 URN Sub-Namespace Registrations 409 This section registers a new XML namespace, as per the guidelines in 410 [7] 412 URI: The URI for this namespace is 413 urn:ietf:params:xml:ns:policy-capabilities. 415 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 416 Jonathan Rosenberg (jdrosen@jdrosen.net). 418 XML: 420 BEGIN 421 422 424 425 426 428 Policy Capabilities Namespace 429 430 431

Namespace for Policy Capabilities

432

urn:ietf:params:xml:ns:policy-capabilities

433

See RFCXXXX[[NOTE 434 TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this 435 specification..

436 437 438 END 440 9.4 XML Schema Registration 442 This section registers an XML schema as per the procedures in [7]. 444 URI: urn:ietf:params:xml:schema:policy-capabilities 446 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 447 Jonathan Rosenberg (jdrosen@jdrosen.net). 449 The XML for this schema can be found as the sole content of 450 Section 5. 452 10. References 454 10.1 Normative References 456 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 457 Levels", BCP 14, RFC 2119, March 1997. 459 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 461 [3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 462 August 1999. 464 [4] Rosenberg, J., "The Extensible Markup Language (XML) 465 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-07 466 (work in progress), June 2005. 468 [5] Schulzrinne, H., "A Document Format for Expressing Privacy 469 Preferences", draft-ietf-geopriv-common-policy-04 (work in 470 progress), February 2005. 472 [6] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 473 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 474 FirstEdition REC-xml-20001006, October 2000. 476 [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 477 January 2004. 479 [8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet 480 Mail Extensions (MIME) Part Four: Registration Procedures", 481 BCP 13, RFC 2048, November 1996. 483 [9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 484 RFC 3023, January 2001. 486 10.2 Informative References 488 [10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 489 and Instant Messaging", RFC 2778, February 2000. 491 [11] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 492 Polk, "Geopriv Requirements", RFC 3693, February 2004. 494 [12] Schulzrinne, H., "A Document Format for Expressing Privacy 495 Preferences for Location Information", 496 draft-ietf-geopriv-policy-05 (work in progress), November 2004. 498 [13] Rosenberg, J., "Presence Authorization Rules", 499 draft-ietf-simple-presence-rules-02 (work in progress), 500 February 2005. 502 Author's Address 504 Jonathan Rosenberg 505 Cisco Systems 506 600 Lanidex Plaza 507 Parsippany, NJ 07054 508 US 510 Phone: +1 973 952-5000 511 Email: jdrosen@cisco.com 512 URI: http://www.jdrosen.net 514 Intellectual Property Statement 516 The IETF takes no position regarding the validity or scope of any 517 Intellectual Property Rights or other rights that might be claimed to 518 pertain to the implementation or use of the technology described in 519 this document or the extent to which any license under such rights 520 might or might not be available; nor does it represent that it has 521 made any independent effort to identify any such rights. Information 522 on the procedures with respect to rights in RFC documents can be 523 found in BCP 78 and BCP 79. 525 Copies of IPR disclosures made to the IETF Secretariat and any 526 assurances of licenses to be made available, or the result of an 527 attempt made to obtain a general license or permission for the use of 528 such proprietary rights by implementers or users of this 529 specification can be obtained from the IETF on-line IPR repository at 530 http://www.ietf.org/ipr. 532 The IETF invites any interested party to bring to its attention any 533 copyrights, patents or patent applications, or other proprietary 534 rights that may cover technology that may be required to implement 535 this standard. Please address the information to the IETF at 536 ietf-ipr@ietf.org. 538 Disclaimer of Validity 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 545 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 548 Copyright Statement 550 Copyright (C) The Internet Society (2005). This document is subject 551 to the rights, licenses and restrictions contained in BCP 78, and 552 except as set forth therein, the authors retain all their rights. 554 Acknowledgment 556 Funding for the RFC Editor function is currently provided by the 557 Internet Society.