idnits 2.17.1 draft-ietf-sip-parameter-registry-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 349. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 365), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (June 16, 2004) is 7252 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) -- Looks like a reference, but probably isn't: 'RFC 3310' on line 273 ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3427 (ref. '4') (Obsoleted by RFC 5727) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: December 15, 2004 June 16, 2004 5 The Internet Assigned Number Authority (IANA) Header Field Parameter 6 Registry for the Session Initiation Protocol (SIP) 7 draft-ietf-sip-parameter-registry-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 15, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document creates an IANA registry for SIP header field 40 parameters and parameter values. It also lists the already existing 41 parameters and parameter values to be used as the initial entries for 42 this registry. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 3 49 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 50 4.1 Header Field Parameters Sub-Registry . . . . . . . . . . . 4 51 4.2 Registration Policy for SIP Header Field Parameters . . . 7 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 53 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 54 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 56 Intellectual Property and Copyright Statements . . . . . . . . 9 58 1. Introduction 60 RFC 3261 [3] allows new header field parameters and new parameter 61 values to be defined. However, RFC3261 omitted an IANA registry for 62 them. This document creates such a registry. 64 RFC 3427 [4] documents the process to extend SIP. This document 65 updates RFC 3427 by specifying how to define and register new SIP 66 header field parameters and parameter values. 68 2. Terminology 70 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 71 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 72 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 73 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 74 compliant implementations. 76 3. Use of the Registry 78 SIP header field parameters and parameter values MUST be documented 79 in an RFC in order to be registered by IANA. This documentation MUST 80 fully explain the syntax, intended usage and semantics of the 81 parameter or parameter value. The intent of this requirement is to 82 assure interoperability between independent implementations, and to 83 prevent accidental namespace collisions between implementations of 84 dissimilar features. 86 Note that this registry, unlike other protocol registries, only 87 deals with parameters and parameter values defined in RFCs (i.e., 88 it lacks a vendor-extension tree). RFC 3427 [4] documents concerns 89 with regards to new SIP extensions which may be damaging towards 90 security, greatly increase the complexity of the protocol, or 91 both. New parameters and parameter values need to be documented in 92 RFCs as a result of these concerns. 94 RFCs defining SIP header field parameters or parameter values MUST 95 register them with IANA as described below. 97 Registered SIP header field parameters and parameter values are to be 98 considered "reserved words". In order to preserve interoperability, 99 registered parameters and parameter values MUST be used in a manner 100 consistent with that described in their defining RFC. Implementations 101 MUST NOT utilize "private" or "locally defined" SIP header field 102 parameters or parameter values that conflict with registered 103 parameters. 105 Note that although unregistered SIP header field parameters and 106 parameter values may be used in implementations, developers are 107 cautioned that usage of such parameters is risky. New SIP header 108 field parameters and parameter values may be registered at any 109 time, and there is no assurance that these new registered 110 parameters or parameter values will not conflict with unregistered 111 parameters currently in use. 113 Some SIP header field parameters only accept a set of predefined 114 parameter values. For example, a parameter indicating the transport 115 protocol in use may only accept as valid values the predefined tokens 116 TCP, UDP, and SCTP. Registering all parameter values for all SIP 117 header field parameters of this type would require a large number of 118 subregistries. Instead, we have chosen to register parameter values 119 by reference. That is, the entry in the parameter registry for a 120 given header field parameter contains references to the RFCs defining 121 new values of the parameter. References to RFCs defining parameter 122 values appear in brackets in the registry. 124 So, the header field parameter registry contains a column that 125 indicates whether or not each parameter only accepts a set of 126 predefined values. Implementers of parameters with a "yes" in that 127 column need to find all the valid parameter values in the RFCs 128 provided as references. 130 4. IANA Considerations 132 Section 27 of RFC 3261 [3] creates an IANA registry for method names, 133 header field names, warning codes, status codes, and option tags. 134 This specification instructs the IANA to create a new sub-registry 135 for header field parameters under 137 http://www.iana.org/assignments/sip-parameters: 139 4.1 Header Field Parameters Sub-Registry 141 The majority of the SIP header fields can be extended by defining new 142 parameters. New SIP header field parameters are registered by the 143 IANA. When registering a new parameter for a header field or a new 144 value for a parameter, the following information MUST be provided. 146 o Header field in which the parameter can appear. 147 o Name of the header field parameter being registered. 148 o Whether the parameter only accepts a set of predefined values. 149 o A reference to the RFC where the parameter is defined and to any 150 RFC that defines new values for the parameter. References to RFCs 151 defining parameter values appear in brackets in the registry. 153 Parameters that can appear in different header fields MAY have the 154 same name. However, parameters that can appear in the same header 155 field MUST have different names. 157 The following are the initial values for this sub-registry. 159 Header Field Parameter Name Predefined Reference 160 Values 161 ___________________________________________________________ 162 Accept q No RFC 3261 163 Accept-Encoding q No RFC 3261 164 Accept-Language q No RFC 3261 165 Authorization algorithm Yes RFC 3261 166 [RFC 3310] 167 Authorization auts No RFC 3310 168 Authorization cnonce No RFC 3261 169 Authorization nc No RFC 3261 170 Authorization nonce No RFC 3261 171 Authorization opaque No RFC 3261 172 Authorization qop Yes RFC 3261 173 Authorization realm No RFC 3261 174 Authorization response No RFC 3261 175 Authorization uri No RFC 3261 176 Authorization username No RFC 3261 177 Authentication-Info cnonce No RFC 3261 178 Authentication-Info nc No RFC 3261 179 Authentication-Info nextnonce No RFC 3261 180 Authentication-Info qop Yes RFC 3261 181 Authentication-Info rspauth No RFC 3261 182 Call-Info purpose Yes RFC 3261 183 Contact expires No RFC 3261 184 Contact q No RFC 3261 185 Content-Disposition handling Yes RFC 3261 186 Event id No RFC 3265 187 From tag No RFC 3261 188 P-Access-Network-Info cgi-3gpp No RFC 3455 189 P-Access-Network-Info utran-cell-id-3gpp No RFC 3455 190 P-Charging-Function-Addresses ccf No RFC 3455 191 P-Charging-Function-Addresses ecf No RFC 3455 192 P-Charging-Vector icid-value No RFC 3455 193 P-Charging-Vector icid-generated-at No RFC 3455 194 P-Charging-Vector orig-ioi No RFC 3455 195 P-Charging-Vector term-ioi No RFC 3455 196 P-DCS-Billing-Info called No RFC 3603 197 P-DCS-Billing-Info calling No RFC 3603 198 P-DCS-Billing-Info charge No RFC 3603 199 P-DCS-Billing-Info locroute No RFC 3603 200 P-DCS-Billing-Info rksgroup No RFC 3603 201 P-DCS-Billing-Info routing No RFC 3603 202 P-DCS-LAES content No RFC 3603 203 P-DCS-LAES key No RFC 3603 204 P-DCS-Redirect count No RFC 3603 205 P-DCS-Redirect redirector-uri No RFC 3603 206 Proxy-Authenticate algorithm Yes RFC 3261 207 [RFC 3310] 208 Proxy-Authenticate domain No RFC 3261 209 Proxy-Authenticate nonce No RFC 3261 210 Proxy-Authenticate opaque No RFC 3261 211 Proxy-Authenticate qop Yes RFC 3261 212 Proxy-Authenticate realm No RFC 3261 213 Proxy-Authenticate stale Yes RFC 3261 214 Proxy-Authorization algorithm Yes RFC 3261 215 [RFC 3310] 216 Proxy-Authorization auts No RFC 3310 217 Proxy-Authorization cnonce No RFC 3261 218 Proxy-Authorization nc No RFC 3261 219 Proxy-Authorization nonce No RFC 3261 220 Proxy-Authorization opaque No RFC 3261 221 Proxy-Authorization qop Yes RFC 3261 222 Proxy-Authorization realm No RFC 3261 223 Proxy-Authorization response No RFC 3261 224 Proxy-Authorization uri No RFC 3261 225 Proxy-Authorization username No RFC 3261 226 Reason cause Yes RFC 3326 227 Reason text No RFC 3326 228 Retry-After duration No RFC 3261 229 Security-Client alg Yes RFC 3329 230 Security-Client ealg Yes RFC 3329 231 Security-Client d-alg Yes RFC 3329 232 Security-Client d-qop Yes RFC 3329 233 Security-Client d-ver No RFC 3329 234 Security-Client mod Yes RFC 3329 235 Security-Client port1 No RFC 3329 236 Security-Client port2 No RFC 3329 237 Security-Client prot Yes RFC 3329 238 Security-Client q No RFC 3329 239 Security-Client spi No RFC 3329 240 Security-Server alg Yes RFC 3329 241 Security-Server ealg Yes RFC 3329 242 Security-Server d-alg Yes RFC 3329 243 Security-Server d-qop Yes RFC 3329 244 Security-Server d-ver No RFC 3329 245 Security-Server mod Yes RFC 3329 246 Security-Server port1 No RFC 3329 247 Security-Server port2 No RFC 3329 248 Security-Server prot Yes RFC 3329 249 Security-Server q No RFC 3329 250 Security-Server spi No RFC 3329 251 Security-Verify alg Yes RFC 3329 252 Security-Verify ealg Yes RFC 3329 253 Security-Verify d-alg Yes RFC 3329 254 Security-Verify d-qop Yes RFC 3329 255 Security-Verify d-ver No RFC 3329 256 Security-Verify mod Yes RFC 3329 257 Security-Verify port1 No RFC 3329 258 Security-Verify port2 No RFC 3329 259 Security-Verify prot Yes RFC 3329 260 Security-Verify q No RFC 3329 261 Security-Verify spi No RFC 3329 262 Subscription-State expires No RFC 3265 263 Subscription-State reason Yes RFC 3265 264 Subscription-State retry-after No RFC 3265 265 To tag No RFC 3261 266 Via branch No RFC 3261 267 Via comp Yes RFC 3486 268 Via maddr No RFC 3261 269 Via received No RFC 3261 270 Via rport No RFC 3581 271 Via ttl No RFC 3261 272 WWW-Authenticate algorithm Yes RFC 3261 273 [RFC 3310] 274 WWW-Authenticate domain Yes RFC 3261 275 WWW-Authenticate nonce No RFC 3261 276 WWW-Authenticate opaque No RFC 3261 277 WWW-Authenticate qop Yes RFC 3261 278 WWW-Authenticate realm No RFC 3261 279 WWW-Authenticate stale Yes RFC 3261 281 4.2 Registration Policy for SIP Header Field Parameters 283 As per the terminology in RFC 2434 [2], the registration policy for 284 SIP header field parameters and parameter values shall be 285 "Specification Required". 287 For the purposes of this registry, the parameter or the parameter 288 value for which IANA registration is requested MUST be defined by an 289 RFC. There is no requirement that this RFC be standards-track. 291 5. Security Considerations 293 There are no security considerations associated to this document. 295 6. Acknowledgements 297 Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki 298 Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule, 299 and Allison Mankin provided useful comments. 301 7 Normative References 303 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 304 Levels", BCP 14, RFC 2119, March 1997. 306 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 307 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 309 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 310 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 311 Session Initiation Protocol", RFC 3261, June 2002. 313 [4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 314 Rosen, "Change Process for the Session Initiation Protocol 315 (SIP)", BCP 67, RFC 3427, December 2002. 317 Author's Address 319 Gonzalo Camarillo 320 Ericsson 321 Hirsalantie 11 322 Jorvas 02420 323 Finland 325 EMail: Gonzalo.Camarillo@ericsson.com 327 Intellectual Property Statement 329 The IETF takes no position regarding the validity or scope of any 330 Intellectual Property Rights or other rights that might be claimed to 331 pertain to the implementation or use of the technology described in 332 this document or the extent to which any license under such rights 333 might or might not be available; nor does it represent that it has 334 made any independent effort to identify any such rights. Information 335 on the IETF's procedures with respect to rights in IETF Documents can 336 be found in BCP 78 and BCP 79. 338 Copies of IPR disclosures made to the IETF Secretariat and any 339 assurances of licenses to be made available, or the result of an 340 attempt made to obtain a general license or permission for the use of 341 such proprietary rights by implementers or users of this 342 specification can be obtained from the IETF on-line IPR repository at 343 http://www.ietf.org/ipr. 345 The IETF invites any interested party to bring to its attention any 346 copyrights, patents or patent applications, or other proprietary 347 rights that may cover technology that may be required to implement 348 this standard. Please address the information to the IETF at 349 ietf-ipr@ietf.org. 351 Disclaimer of Validity 353 This document and the information contained herein are provided on an 354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 356 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 357 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 358 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 361 Copyright Statement 363 Copyright (C) The Internet Society (2004). This document is subject 364 to the rights, licenses and restrictions contained in BCP 78, and 365 except as set forth therein, the authors retain all their rights. 367 Acknowledgment 369 Funding for the RFC Editor function is currently provided by the 370 Internet Society.