idnits 2.17.1 draft-ietf-simple-pres-policy-caps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. ** 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 (June 26, 2006) is 6512 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) -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-07 Summary: 4 errors (**), 0 flaws (~~), 3 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: December 28, 2006 June 26, 2006 6 An Extensible Markup Language (XML) Representation for Expressing 7 Presence Policy Capabilities 8 draft-ietf-simple-pres-policy-caps-01 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 December 28, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 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 [5] 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-07 (work in progress), 280 June 2006. 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] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and 291 Instant Messaging", RFC 2778, February 2000. 293 Author's Address 295 Jonathan Rosenberg 296 Cisco Systems 297 600 Lanidex Plaza 298 Parsippany, NJ 07054 299 US 301 Phone: +1 973 952-5000 302 Email: jdrosen@cisco.com 303 URI: http://www.jdrosen.net 305 Intellectual Property Statement 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Disclaimer of Validity 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 334 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 335 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 336 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Copyright Statement 341 Copyright (C) The Internet Society (2006). This document is subject 342 to the rights, licenses and restrictions contained in BCP 78, and 343 except as set forth therein, the authors retain all their rights. 345 Acknowledgment 347 Funding for the RFC Editor function is currently provided by the 348 Internet Society.