idnits 2.17.1 draft-camarillo-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 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 58: '...ietary header field parameters MUST be...' RFC 2119 keyword, line 78: '...ollowing information MUST be provided....' RFC 2119 keyword, line 95: '...n different header fields MAY have the...' RFC 2119 keyword, line 97: '... field MUST have different names....' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 111 has weird spacing: '...dresses ccf ...' == Line 112 has weird spacing: '...dresses ecf ...' -- 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 17, 2003) is 7618 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: 4 errors (**), 0 flaws (~~), 4 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-camarillo-sip-parameter-registry-01.txt 6 June 17, 2003 7 Expires: December 2003 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 Use of the Registry ................................. 3 43 3 IANA Considerations ................................. 3 44 3.1 Header Field Parameters Sub-Registry ................ 3 45 4 Security Considerations ............................. 4 46 5 Acknowledgements .................................... 4 47 6 Authors' Addresses .................................. 4 48 7 Normative References ................................ 5 50 1 Introduction 52 RFC3261 [1] allows new header field parameters to be defined. 53 However, RFC3261 omitted an IANA registry for them. This document 54 creates such a registry. 56 2 Use of the Registry 58 Both RFC defined and proprietary header field parameters MUST be 59 registered with IANA as described below. 61 Note that this includes header field parameters for P- 62 headers. 64 3 IANA Considerations 66 Section 27 of RFC 3261 [1] creates an IANA registry for method names, 67 header field names, warning codes, status codes, and option tags. 68 This specification instructs the IANA to create two a new sub- 69 registry under http://www.iana.org/assignments/sip-parameters: 71 o Header Field Parameters 73 3.1 Header Field Parameters Sub-Registry 75 The majority of the SIP header fields can be extended by defining new 76 parameters. New SIP header field parameters are registered by the 77 IANA. When registering a new parameter for a header field, the 78 following information MUST be provided. 80 o Header field in which the parameter can appear. 82 o Name of the parameter. 84 o For proprietary parameters, a brief description of its 85 semantics. 87 o A reference to a further description, if available. For 88 example, (in order of preference) an RFC, a published paper, a 89 patent filing, a technical report, documented source code or a 90 computer manual. 92 o For proprietary parameters, contact information (postal and 93 email address). 95 Parameters that can appear in different header fields MAY have the 96 same name. However, parameters that can appear in the same header 97 field MUST have different names. 99 Table 1 contains the initial values for this sub-registry. 101 Header Field Parameter Name Description Reference 102 ________________________________________________________________________ 103 Accept q RFC 3261 104 Accept-Encoding q RFC 3261 105 Accept-Language q RFC 3261 106 Call-Info purpose RFC 3261 107 Contact expires RFC 3261 108 Contact q RFC 3261 109 Content-Disposition handling RFC 3261 110 From tag RFC 3261 111 P-Charging-Function-Addresses ccf RFC 3455 112 P-Charging-Function-Addresses ecf RFC 3455 113 P-Charging-Vector icid-value RFC 3455 114 P-Charging-Vector icid-generated-at RFC 3455 115 P-Charging-Vector orig-ioi RFC 3455 116 P-Charging-Vector term-ioi RFC 3455 117 Retry-After duration RFC 3261 118 To tag RFC 3261 119 Via branch RFC 3261 120 Via comp RFC 3486 121 Via maddr RFC 3261 122 Via received RFC 3261 123 Via rport [symmetric] 124 Via ttl RFC 3261 126 Table 1: IANA SIP header field parameter sub-registry 128 4 Security Considerations 130 There are no security considerations associated to this document. 132 5 Acknowledgements 134 Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy and Dean Willis 135 provided useful comments. 137 6 Authors' Addresses 139 Gonzalo Camarillo 140 Ericsson 141 Advanced Signalling Research Lab. 142 FIN-02420 Jorvas 143 Finland 144 electronic mail: Gonzalo.Camarillo@ericsson.com 146 7 Normative References 148 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 149 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 150 initiation protocol," RFC 3261, Internet Engineering Task Force, June 151 2002. 153 The IETF takes no position regarding the validity or scope of any 154 intellectual property or other rights that might be claimed to 155 pertain to the implementation or use of the technology described in 156 this document or the extent to which any license under such rights 157 might or might not be available; neither does it represent that it 158 has made any effort to identify any such rights. Information on the 159 IETF's procedures with respect to rights in standards-track and 160 standards-related documentation can be found in BCP-11. Copies of 161 claims of rights made available for publication and any assurances of 162 licenses to be made available, or the result of an attempt made to 163 obtain a general license or permission for the use of such 164 proprietary rights by implementors or users of this specification can 165 be obtained from the IETF Secretariat. 167 The IETF invites any interested party to bring to its attention any 168 copyrights, patents or patent applications, or other proprietary 169 rights which may cover technology that may be required to practice 170 this standard. Please address the information to the IETF Executive 171 Director. 173 Full Copyright Statement 175 Copyright (c) The Internet Society (2003). All Rights Reserved. 177 This document and translations of it may be copied and furnished to 178 others, and derivative works that comment on or otherwise explain it 179 or assist in its implementation may be prepared, copied, published 180 and distributed, in whole or in part, without restriction of any 181 kind, provided that the above copyright notice and this paragraph are 182 included on all such copies and derivative works. However, this 183 document itself may not be modified in any way, such as by removing 184 the copyright notice or references to the Internet Society or other 185 Internet organizations, except as needed for the purpose of 186 developing Internet standards in which case the procedures for 187 copyrights defined in the Internet Standards process must be 188 followed, or as required to translate it into languages other than 189 English. 191 The limited permissions granted above are perpetual and will not be 192 revoked by the Internet Society or its successors or assigns. 194 This document and the information contained herein is provided on an 195 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 196 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 197 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 198 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 199 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.