idnits 2.17.1 draft-camarillo-sipping-consent-reg-event-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 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2006) is 6633 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) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-consent-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-framework (ref. '5') Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING G. Camarillo 3 Internet-Draft Ericsson 4 Expires: August 29, 2006 February 25, 2006 6 Session Initiation Protocol (SIP) Registration Event Package Extension 7 for Consent-Based Communications 8 draft-camarillo-sipping-consent-reg-event-00.txt 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 August 29, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines an extension to the SIP registration event 42 package for communicating whether or not a registrar has obtained 43 permission to perform a translation that was set up through a 44 registration. This extension is used by registrars implementing the 45 framework for consent-based communications in SIP. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . . 3 53 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 3 54 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 4 55 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 8. XML Schema Definition . . . . . . . . . . . . . . . . . . . . . 4 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 9.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 5 59 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . . 6 60 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 9 67 1. Introduction 69 The framework for consent-based communications in SIP [5] identifies 70 the need for registrars to inform user agents about the consent- 71 related status of their registrations. That is, user agents need to 72 know whether or not their registrar has obtained permission to 73 perform a particular translation that was set up through a 74 registration. 76 User agents are kept informed about the status of their registrations 77 using the SIP [2] registration event package [3]. This event package 78 has provision for including extension elements within the 79 element. This document defines a new element called 80 that may be used to deliver the consent-related status of a 81 registration. 83 2. Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 87 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 88 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 89 compliant implementations. 91 3. Description 93 A new element is defined which contains the consent- 94 related status of a registration. This element can take the 95 following values: 'pending', 'granted', or 'denied'. 97 This optional element is included within the body of a NOTIFY for the 98 "reg" event package when the framework for consent-communications in 99 SIP is used. The contact URI and the consent-related status are then 100 both available to the watcher. 102 4. Notifier Processing of SUBSCRIBE Requests 104 Unchanged from RFC 3680 [3]. 106 5. Notifier Generation of NOTIFY Requests 108 A notifier for the "reg" event package [3] SHOULD include the 109 element when the framework for consent-based 110 communications in SIP is used. When present, the 111 element MUST be positioned as an instance of the element within 112 the element. 114 6. Subscriber Processing of NOTIFY Requests 116 Subscribers receive information about the consent-related status of 117 registrations in "reg" event notifications with elements 118 containing elements. 120 Subscribers that are unaware of this extension will, as required by 121 [3], ignore the element. 123 7. Example 125 The following is an example registration information document 126 including the new element: 128 129 133 135 138 sip:user@192.0.2.1 139 pending 140 141 142 144 8. XML Schema Definition 146 A consent-status document is an XML document that MUST be well-formed 147 and SHOULD be valid. Consent-status documents MUST be based on XML 148 1.0 and MUST be encoded using UTF-8. This specification makes use of 149 XML namespaces for identifying consent-status documents. The 150 namespace URI for elements defined for this purpose is a URN, using 151 the namespace identifier 'ietf'. This URN is: 153 urn:ietf:params:xml:ns:consent-status 155 BEGIN 156 157 162 163 164 165 166 167 168 169 170 171 172 END 174 9. IANA Considerations 176 There are two IANA considerations associated with this specification. 178 9.1. URN Sub-Namespace Registration 180 This section registers a new XML namespace, per the guidelines in 181 [4]. 183 URI: The URI for this namespace is 184 urn:ietf:params:xml:ns:consent-status 186 Registrant Contact: IETF, SIPPING working group, , 187 Gonzalo Camarillo 188 XML: 190 BEGIN 191 192 194 195 196 198 Consent-related Status Extension Namespace 199 200 201

Namespace for Consent-related Status Information Extension

202

urn:ietf:params:xml:ns:consent-status

203

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

206 207 208 END 210 9.2. XML Schema Registration 212 This section registers an XML schema per the procedures in [4]. 214 URI: urn:ietf:params:xml:schema:consent-status. 216 Registrant Contact: IETF, SIPPING working group, , 217 Gonzalo Camarillo 219 The XML for this schema can be found in Section 8. 221 10. Security Considerations 223 Security considerations for the registration event package are 224 discussed in RFC 3680 [3], and those considerations apply here. 226 The addition of consent-related information does not impact security 227 negatively because that information is less sensitive than the 228 contact URI itself. 230 11. References 231 11.1. Normative References 233 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 234 Levels", BCP 14, RFC 2119, March 1997. 236 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 237 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 238 Session Initiation Protocol", RFC 3261, June 2002. 240 [3] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 241 Package for Registrations", RFC 3680, March 2004. 243 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 244 January 2004. 246 [5] Rosenberg, J., "A Framework for Consent-Based Communications in 247 the Session Initiation Protocol (SIP)", 248 draft-ietf-sipping-consent-framework-03 (work in progress), 249 October 2005. 251 11.2. Informative References 252 Author's Address 254 Gonzalo Camarillo 255 Ericsson 256 Hirsalantie 11 257 Jorvas 02420 258 Finland 260 Email: Gonzalo.Camarillo@ericsson.com 262 Intellectual Property Statement 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the procedures with respect to rights in RFC documents can be 271 found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at 284 ietf-ipr@ietf.org. 286 Disclaimer of Validity 288 This document and the information contained herein are provided on an 289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 291 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 292 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 293 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 296 Copyright Statement 298 Copyright (C) The Internet Society (2006). This document is subject 299 to the rights, licenses and restrictions contained in BCP 78, and 300 except as set forth therein, the authors retain all their rights. 302 Acknowledgment 304 Funding for the RFC Editor function is currently provided by the 305 Internet Society.