idnits 2.17.1 draft-ietf-sip-parameter-registry-00.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 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 110 has weird spacing: '...dresses ccf ...' == Line 111 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 (August 18, 2003) is 7528 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) No issues found here. Summary: 2 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-00.txt 6 August 18, 2003 7 Expires: February 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 ................ 3 46 5 Security Considerations ............................. 4 47 6 Acknowledgements .................................... 4 48 7 Authors' Addresses .................................. 4 49 8 Normative References ................................ 5 51 1 Introduction 53 RFC3261 [1] allows new header field parameters to be defined. 54 However, RFC3261 omitted an IANA registry for them. This document 55 creates such a registry. 57 2 Terminology 59 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 60 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 61 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 62 indicate requirement levels for compliant SIP implementations. 64 3 Use of the Registry 66 RFCs defining new header field parameters MUST register them with the 67 IANA as described below. 69 Note that this includes header field parameters defined in 70 informational RFCs for P-headers. 72 4 IANA Considerations 74 Section 27 of RFC 3261 [1] creates an IANA registry for method names, 75 header field names, warning codes, status codes, and option tags. 76 This specification instructs the IANA to create two a new sub- 77 registry under http://www.iana.org/assignments/sip-parameters: 79 o Header Field Parameters 81 4.1 Header Field Parameters Sub-Registry 83 The majority of the SIP header fields can be extended by defining new 84 parameters. New SIP header field parameters are registered by the 85 IANA. When registering a new parameter for a header field, the 86 following information MUST be provided. 88 o Header field in which the parameter can appear. 90 o Name of the parameter. 92 o A reference to the RFC were the parameter is defined. 94 Parameters that can appear in different header fields MAY have the 95 same name. However, parameters that can appear in the same header 96 field MUST have different names. 98 Table 1 contains the initial values for this sub-registry. 100 Header Field Parameter Name Reference 101 ______________________________________________________________ 102 Accept q RFC 3261 103 Accept-Encoding q RFC 3261 104 Accept-Language q RFC 3261 105 Call-Info purpose RFC 3261 106 Contact expires RFC 3261 107 Contact q RFC 3261 108 Content-Disposition handling RFC 3261 109 From tag RFC 3261 110 P-Charging-Function-Addresses ccf RFC 3455 111 P-Charging-Function-Addresses ecf RFC 3455 112 P-Charging-Vector icid-value RFC 3455 113 P-Charging-Vector icid-generated-at RFC 3455 114 P-Charging-Vector orig-ioi RFC 3455 115 P-Charging-Vector term-ioi RFC 3455 116 Retry-After duration RFC 3261 117 To tag RFC 3261 118 Via branch RFC 3261 119 Via comp RFC 3486 120 Via maddr RFC 3261 121 Via received RFC 3261 122 Via rport [symmetric] 123 Via ttl RFC 3261 125 Table 1: IANA SIP header field parameter sub-registry 127 5 Security Considerations 129 There are no security considerations associated to this document. 131 6 Acknowledgements 133 Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy and Dean Willis 134 provided useful comments. 136 7 Authors' Addresses 138 Gonzalo Camarillo 139 Ericsson 140 Advanced Signalling Research Lab. 141 FIN-02420 Jorvas 142 Finland 143 electronic mail: Gonzalo.Camarillo@ericsson.com 145 8 Normative References 147 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 148 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 149 initiation protocol," RFC 3261, Internet Engineering Task Force, June 150 2002. 152 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 153 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 155 The IETF takes no position regarding the validity or scope of any 156 intellectual property or other rights that might be claimed to 157 pertain to the implementation or use of the technology described in 158 this document or the extent to which any license under such rights 159 might or might not be available; neither does it represent that it 160 has made any effort to identify any such rights. Information on the 161 IETF's procedures with respect to rights in standards-track and 162 standards-related documentation can be found in BCP-11. Copies of 163 claims of rights made available for publication and any assurances of 164 licenses to be made available, or the result of an attempt made to 165 obtain a general license or permission for the use of such 166 proprietary rights by implementors or users of this specification can 167 be obtained from the IETF Secretariat. 169 The IETF invites any interested party to bring to its attention any 170 copyrights, patents or patent applications, or other proprietary 171 rights which may cover technology that may be required to practice 172 this standard. Please address the information to the IETF Executive 173 Director. 175 Full Copyright Statement 177 Copyright (c) The Internet Society (2003). All Rights Reserved. 179 This document and translations of it may be copied and furnished to 180 others, and derivative works that comment on or otherwise explain it 181 or assist in its implementation may be prepared, copied, published 182 and distributed, in whole or in part, without restriction of any 183 kind, provided that the above copyright notice and this paragraph are 184 included on all such copies and derivative works. However, this 185 document itself may not be modified in any way, such as by removing 186 the copyright notice or references to the Internet Society or other 187 Internet organizations, except as needed for the purpose of 188 developing Internet standards in which case the procedures for 189 copyrights defined in the Internet Standards process must be 190 followed, or as required to translate it into languages other than 191 English. 193 The limited permissions granted above are perpetual and will not be 194 revoked by the Internet Society or its successors or assigns. 196 This document and the information contained herein is provided on an 197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.