idnits 2.17.1 draft-ietf-simple-pres-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 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 331. ** 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 11 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 6863 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: '5' is defined on line 290, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-02 == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-07 Summary: 4 errors (**), 0 flaws (~~), 5 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 7 Presence Policy Capabilities 8 draft-ietf-simple-pres-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 services is policy. Policy 42 systems allow the presentity to grant access to specific pieces of 43 information to specific watchers. To allow for interoperability 44 between clients which set such policies, and servers which execute 45 them, it is necessary for clients to be able to determine the 46 capabilities of the server to which it is connected. This 47 specification defines a set of Extensible Markup Language (XML) 48 elements for expressing presence policy capabilities. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Structure of Presence Policy Capabilities . . . . . . . . . . 3 55 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7.1 URN Sub-Namespace Registrations . . . . . . . . . . . . . 6 60 7.2 XML Schema Registration . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 63 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . 9 67 1. Terminology 69 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 70 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 71 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 72 indicate requirement levels for compliant implementations. 74 2. Introduction 76 An important component of presence [6] is policy. Policy systems 77 allow the presentity to grant access to specific pieces of 78 information to specific watchers. These policy systems can be 79 extremely simple or extremely complex. For this reason [1] defines a 80 generic Extensible Markup Language (XML) based format for 81 representing policy capabilities. That format applies to many 82 services, including location and presence. This specification 83 extends that one by defining policy capabilities specific to 84 presence. Those policy capabilities correspond to the conditions, 85 actions and transformations defined in [2]. 87 3. Structure of Presence Policy Capabilities 89 [1] defines the structure of common policy capability documents. In 90 that specification, each policy capability document has three 91 components - a list of supported conditions, a list of supported 92 actions, and a list of supported transformations. This specification 93 merely extends that document with the conditions, actions and 94 transformations defined in [2]. It does so by defining the elements 95 , and , each of 96 which is a presence transformation that the server can support. 97 Furthermore, each of those includes elements that define the specific 98 ways of identifying services, devices and persons, respectively. 100 The document also defines capabilities for transformations that 101 provide individual presence attributes, including , , , , 103 , , , 104 , , , 105 , , , 106 , , and , each of which is a boolean indicating whether that 108 transformation is supported. 110 Finally, this document defines the element, which is a 111 boolean indicating whether or not the corresponding action is 112 supported. 114 OPEN ISSUE: should we define capabilities for specific values of 115 sub-handling and component-id? 117 All of these elements are defined within the namespace: 119 urn:ietf:params:xml:ns:presence-policy-capabilities 121 4. XML Schema 123 124 130 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 182 5. Example Document 184 The following document is an example. 186 187 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 214 NOTE: this example needs work - doens't validate against the 215 schema. 217 6. Security Considerations 219 This specification does not introduce any new security considerations 220 beyond those discussed in [1]. 222 7. IANA Considerations 224 There are several IANA considerations associated with this 225 specification. 227 7.1 URN Sub-Namespace Registrations 229 This section registers a new XML namespace, as per the guidelines in 230 [4] 231 URI: The URI for this namespace is 232 urn:ietf:params:xml:ns:presence-policy-capabilities 234 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 235 Jonathan Rosenberg (jdrosen@jdrosen.net). 237 XML: 239 BEGIN 240 241 243 244 245 247 Supported Presence Permissions Namespace 248 249 250

Namespace for Supported Permissions

251

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

252

See RFCXXXX.

253 254 255 END 257 7.2 XML Schema Registration 259 This section registers an XML schema as per the procedures in [4]. 261 URI: urn:ietf:params:xml:schema:presence-policy-capabilities. 263 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 264 Jonathan Rosenberg (jdrosen@jdrosen.net). 266 The XML for this schema can be found as the sole content of 267 Section 4. 269 8. References 271 8.1 Normative References 273 [1] Rosenberg, J., "An Extensible Markup Language (XML) 274 Representation for Expressing Policy Capabilities", 275 draft-rosenberg-simple-common-policy-caps-02 (work in progress), 276 February 2005. 278 [2] Rosenberg, J., "Presence Authorization Rules", 279 draft-ietf-simple-presence-rules-02 (work in progress), 280 February 2005. 282 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 283 Levels", BCP 14, RFC 2119, March 1997. 285 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 286 January 2004. 288 8.2 Informative References 290 [5] Rosenberg, J., "The Extensible Markup Language (XML) 291 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-07 292 (work in progress), June 2005. 294 [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and 295 Instant Messaging", RFC 2778, February 2000. 297 Author's Address 299 Jonathan Rosenberg 300 Cisco Systems 301 600 Lanidex Plaza 302 Parsippany, NJ 07054 303 US 305 Phone: +1 973 952-5000 306 Email: jdrosen@cisco.com 307 URI: http://www.jdrosen.net 309 Intellectual Property Statement 311 The IETF takes no position regarding the validity or scope of any 312 Intellectual Property Rights or other rights that might be claimed to 313 pertain to the implementation or use of the technology described in 314 this document or the extent to which any license under such rights 315 might or might not be available; nor does it represent that it has 316 made any independent effort to identify any such rights. Information 317 on the procedures with respect to rights in RFC documents can be 318 found in BCP 78 and BCP 79. 320 Copies of IPR disclosures made to the IETF Secretariat and any 321 assurances of licenses to be made available, or the result of an 322 attempt made to obtain a general license or permission for the use of 323 such proprietary rights by implementers or users of this 324 specification can be obtained from the IETF on-line IPR repository at 325 http://www.ietf.org/ipr. 327 The IETF invites any interested party to bring to its attention any 328 copyrights, patents or patent applications, or other proprietary 329 rights that may cover technology that may be required to implement 330 this standard. Please address the information to the IETF at 331 ietf-ipr@ietf.org. 333 Disclaimer of Validity 335 This document and the information contained herein are provided on an 336 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 337 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 338 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 339 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 340 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 341 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 343 Copyright Statement 345 Copyright (C) The Internet Society (2005). This document is subject 346 to the rights, licenses and restrictions contained in BCP 78, and 347 except as set forth therein, the authors retain all their rights. 349 Acknowledgment 351 Funding for the RFC Editor function is currently provided by the 352 Internet Society.