idnits 2.17.1 draft-ietf-sip-parameter-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 223 has weird spacing: '...dresses ccf ...' == Line 224 has weird spacing: '...dresses ecf ...' == 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 (November 24, 2003) is 7459 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) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo 4 Ericsson 5 draft-ietf-sip-parameter-registry-01.txt 6 November 24, 2003 7 Expires: May 2004 9 The Internet Assigned Number Authority Header Field 10 Parameter Registry for the Session Initiation Protocol 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document creates an IANA registry for SIP header field 36 parameters. It also lists the already existing parameters to be used 37 as initial values for that registry. 39 Table of Contents 41 1 Introduction ........................................ 3 42 2 Terminology ......................................... 3 43 3 Use of the Registry ................................. 3 44 4 IANA Considerations ................................. 3 45 4.1 Header Field Parameters Sub-Registry ................ 4 46 4.2 Registration Policy for SIP Header Field 47 Parameters .......................................... 4 48 5 Security Considerations ............................. 4 49 6 Acknowledgements .................................... 4 50 7 Authors' Addresses .................................. 4 51 8 Normative References ................................ 4 52 9 Informative References .............................. 5 54 1 Introduction 56 RFC3261 [1] allows new header field parameters to be defined. 57 However, RFC3261 omitted an IANA registry for them. This document 58 creates such a registry. 60 2 Terminology 62 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 63 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 64 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 65 indicate requirement levels for compliant SIP implementations. 67 3 Use of the Registry 69 SIP header field parameters MUST be documented in an RFC in order to 70 be registered by IANA. This documentation MUST fully explain the 71 syntax, intended usage and semantics of the parameter. The intent of 72 this requirement is to assure inetroperability between independent 73 implementations, and to prevent accidental namespace collisions 74 between implementations of dissimialr features. 76 RFCs defining SIP header field parameters MUST register them with 77 IANA as described below. 79 Registered SIP header field parameters are to be considered "reserved 80 words". In order to preserve interoperability, registered parameters 81 MUST be used in a manner consistent with that described in their 82 defining RFC. Implementations MUST NOT utilize "private" or "locally 83 defined" SIP header field parameters that conflict with registered 84 parameters. 86 Note that although unregistered SIP header field parameters 87 may be used in implementations, developers are cautioned 88 that usage of such parameters is risky. New SIP header 89 field parameters may be registered at any time, and there 90 is no assurance that these new registered URI parameters 91 will not conflict with unregistered parameters currently in 92 use. 94 4 IANA Considerations 96 Section 27 of RFC 3261 [1] creates an IANA registry for method names, 97 header field names, warning codes, status codes, and option tags. 98 This specification instructs the IANA to create a new sub-registry 99 under http://www.iana.org/assignments/sip-parameters: 101 o Header Field Parameters 103 4.1 Header Field Parameters Sub-Registry 105 The majority of the SIP header fields can be extended by defining new 106 parameters. New SIP header field parameters are registered by the 107 IANA. When registering a new parameter for a header field, the 108 following information MUST be provided. 110 o Header field in which the parameter can appear. 112 o Name of the parameter. 114 o A reference to the RFC were the parameter is defined. 116 Parameters that can appear in different header fields MAY have the 117 same name. However, parameters that can appear in the same header 118 field MUST have different names. 120 Table 1 contains the initial values for this sub-registry. 122 4.2 Registration Policy for SIP Header Field Parameters 124 As per the terminology in RFC 2434 [3], the registration policy for 125 SIP header field parameters shall be "Specification Required". 127 For the purposes of this registry, the parameter for which IANA 128 registration is requested MUST be defined by an RFC. There is no 129 requirement that this RFC be standards-track. 131 5 Security Considerations 133 There are no security considerations associated to this document. 135 6 Acknowledgements 137 Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki 138 Niemi, and Bill Marshall provided useful comments. 140 7 Authors' Addresses 142 Gonzalo Camarillo 143 Ericsson 144 Advanced Signalling Research Lab. 145 FIN-02420 Jorvas 146 Finland 147 electronic mail: Gonzalo.Camarillo@ericsson.com 149 8 Normative References 151 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 152 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 153 initiation protocol," RFC 3261, Internet Engineering Task Force, June 154 2002. 156 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 157 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 159 [3] T. Narten and H. Alvestrand, "Guidelines for writing an IANA 160 considerations section in RFCs," RFC 2434, Internet Engineering Task 161 Force, Oct. 1998. 163 9 Informative References 165 The IETF takes no position regarding the validity or scope of any 166 intellectual property or other rights that might be claimed to 167 pertain to the implementation or use of the technology described in 168 this document or the extent to which any license under such rights 169 might or might not be available; neither does it represent that it 170 has made any effort to identify any such rights. Information on the 171 IETF's procedures with respect to rights in standards-track and 172 standards-related documentation can be found in BCP-11. Copies of 173 claims of rights made available for publication and any assurances of 174 licenses to be made available, or the result of an attempt made to 175 obtain a general license or permission for the use of such 176 proprietary rights by implementors or users of this specification can 177 be obtained from the IETF Secretariat. 179 The IETF invites any interested party to bring to its attention any 180 copyrights, patents or patent applications, or other proprietary 181 rights which may cover technology that may be required to practice 182 this standard. Please address the information to the IETF Executive 183 Director. 185 Full Copyright Statement 187 Copyright (c) The Internet Society (2003). All Rights Reserved. 189 This document and translations of it may be copied and furnished to 190 others, and derivative works that comment on or otherwise explain it 191 or assist in its implementation may be prepared, copied, published 192 and distributed, in whole or in part, without restriction of any 193 kind, provided that the above copyright notice and this paragraph are 194 included on all such copies and derivative works. However, this 195 document itself may not be modified in any way, such as by removing 196 the copyright notice or references to the Internet Society or other 197 Header Field Parameter Name Reference 198 ____________________________________________________________ 199 Accept q RFC 3261 200 Accept-Encoding q RFC 3261 201 Accept-Language q RFC 3261 202 Authorization algorithm RFC 3261 203 Authorization cnonce RFC 3261 204 Authorization nc RFC 3261 205 Authorization nonce RFC 3261 206 Authorization opaque RFC 3261 207 Authorization qop RFC 3261 208 Authorization realm RFC 3261 209 Authorization response RFC 3261 210 Authorization uri RFC 3261 211 Authorization username RFC 3261 212 Authentication-Info cnonce RFC 3261 213 Authentication-Info nc RFC 3261 214 Authentication-Info nextnonce RFC 3261 215 Authentication-Info qop RFC 3261 216 Authentication-Info rspauth RFC 3261 217 Call-Info purpose RFC 3261 218 Contact expires RFC 3261 219 Contact q RFC 3261 220 Content-Disposition handling RFC 3261 221 Event id RFC 3265 222 From tag RFC 3261 223 P-Charging-Function-Addresses ccf RFC 3455 224 P-Charging-Function-Addresses ecf RFC 3455 225 P-Charging-Vector icid-value RFC 3455 226 P-Charging-Vector icid-generated-at RFC 3455 227 P-Charging-Vector orig-ioi RFC 3455 228 P-Charging-Vector term-ioi RFC 3455 229 P-DCS-Billing-Info called RFC 3603 230 P-DCS-Billing-Info calling RFC 3603 231 P-DCS-Billing-Info charge RFC 3603 232 P-DCS-Billing-Info locroute RFC 3603 233 P-DCS-Billing-Info rksgroup RFC 3603 234 P-DCS-Billing-Info routing RFC 3603 235 P-DCS-LAES content RFC 3603 236 P-DCS-LAES key RFC 3603 237 P-DCS-Redirect count RFC 3603 238 P-DCS-Redirect redirector-uri RFC 3603 239 Proxy-Authenticate algorithm RFC 3261 240 Proxy-Authenticate domain RFC 3261 241 Proxy-Authenticate nonce RFC 3261 242 Proxy-Authenticate opaque RFC 3261 243 Proxy-Authenticate qop RFC 3261 244 Proxy-Authenticate realm RFC 3261 245 Reason text RFC 3326 246 Retry-After duration RFC 3261 247 Security-Client alg RFC 3329 248 Security-Client ealg RFC 3329 249 Security-Client d-alg RFC 3329 250 Security-Client d-qop RFC 3329 251 Security-Client d-ver RFC 3329 252 Security-Client mod RFC 3329 253 Security-Client port1 RFC 3329 254 Security-Client port2 RFC 3329 255 Security-Client prot RFC 3329 256 Security-Client q RFC 3329 257 Security-Client spi RFC 3329 258 Security-Server alg RFC 3329 259 Security-Server ealg RFC 3329 260 Security-Server d-alg RFC 3329 261 Security-Server d-qop RFC 3329 262 Security-Server d-ver RFC 3329 263 Security-Server mod RFC 3329 264 Security-Server port1 RFC 3329 265 Security-Server port2 RFC 3329 266 Security-Server prot RFC 3329 267 Security-Server q RFC 3329 268 Security-Server spi RFC 3329 269 Security-Verify alg RFC 3329 270 Security-Verify ealg RFC 3329 271 Security-Verify d-alg RFC 3329 272 Security-Verify d-qop RFC 3329 273 Security-Verify d-ver RFC 3329 274 Security-Verify mod RFC 3329 275 Security-Verify port1 RFC 3329 276 Security-Verify port2 RFC 3329 277 Security-Verify prot RFC 3329 278 Security-Verify q RFC 3329 279 Security-Verify spi RFC 3329 280 Subscription-State expires RFC 3265 281 Subscription-State reason RFC 3265 282 Subscription-State retry-after RFC 3265 283 To tag RFC 3261 284 Via branch RFC 3261 285 Via comp RFC 3486 286 Via maddr RFC 3261 287 Via received RFC 3261 288 Via rport RFC 3581 289 Via ttl RFC 3261 290 WWW-Authenticate algorithm RFC 3261 291 WWW-Authenticate domain RFC 3261 292 WWW-Authenticate nonce RFC 3261 293 WWW-Authenticate opaque RFC 3261 294 WWW-Authenticate qop RFC 3261 295 WWW-Authenticate realm RFC 3261 297 Table 1: IANA SIP header field parameter sub-registry 299 Internet organizations, except as needed for the purpose of 300 developing Internet standards in which case the procedures for 301 copyrights defined in the Internet Standards process must be 302 followed, or as required to translate it into languages other than 303 English. 305 The limited permissions granted above are perpetual and will not be 306 revoked by the Internet Society or its successors or assigns. 308 This document and the information contained herein is provided on an 309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.