idnits 2.17.1 draft-garcia-sipping-etsi-ngn-p-headers-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 328. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 == Line 227 has weird spacing: '... where proxy...' == Line 281 has weird spacing: '...ort for the E...' == 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 (July 1, 2005) is 6873 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) == Missing Reference: 'RFCXXXX' is mentioned on line 252, but not defined ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-04) exists of draft-jesske-sipping-tispan-requirements-01 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Garcia-Martin 3 Internet-Draft Nokia 4 Expires: January 2, 2006 July 1, 2005 6 Private Header (P-Header) Extensions to the Session Initiation Protocol 7 (SIP) in support of the European Telecommunications Standards Institute 8 (ETSI) Next Generation Networks (NGN) 9 draft-garcia-sipping-etsi-ngn-p-headers-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a private SIP header field (P-header) used by 43 the European Telecommunications Standards Institte (ETSI) in Next 44 Generation Networks (NGN). The P-header is used for triggering 45 services. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Overall Applicability . . . . . . . . . . . . . . . . . . . . 3 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . . 3 53 4.1 The SIP P-AoC header field . . . . . . . . . . . . . . . . 3 54 4.1.1 Applicability statement of the P-AoC header field . . 4 55 4.1.2 Usage of the SIP P-AoC header field . . . . . . . . . 4 56 4.1.3 Syntax of the P-AoC header field . . . . . . . . . . . 5 57 4.1.4 Table of methods . . . . . . . . . . . . . . . . . . . 6 58 4.2 Security Considerations . . . . . . . . . . . . . . . . . 6 59 4.3 IANA Considerations . . . . . . . . . . . . . . . . . . . 6 60 4.4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 7 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1 Normative References . . . . . . . . . . . . . . . . . . . 7 63 5.2 Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . 9 67 1. Introduction 69 The European Telecommunication Standards Institute (ETSI) is 70 defininig a Next Generation Network (NGN) where a substantial part of 71 it is based on the IP Multimedia Subsystem (IMS) defined by the 72 Third-Generation Partnership Project (3GPP). IMS is largely based on 73 the Session Initiation Protocol [RFC3261]. 75 ETSI has developed a number of requirements [I-D.jesske-sipping- 76 tispan-requirements] to support the usage of SIP in Next Generation 77 Networks that interoperate, at the service level, with the Public 78 Switched Telephone Network (PSTN), the Integrated Services Digital 79 Network (ISDN), the 3GPP IP Multimedia Subsystem (IMS), and SIP 80 networks and terminals that implement the service logic. 82 In order to provide full support in SIP of existing services, 83 extensions to SIP are needed. This document defines a number of 84 Private headers (P- headers) to support those services. 86 2. Overall Applicability 88 The SIP extensions specified in this document make certain 89 assumptions regarding network topology, linkage between SIP and lower 90 layers, and the availability of transitive trust. These assumptions 91 are generally NOT APPLICABLE in the Internet as a whole. The 92 mechanisms specified here were designed to satisfy the requirements 93 specified by ETSI NGN [I-D.jesske-sipping-tispan-requirements] for 94 which either no general-purpose solution was planned, where 95 insufficient operational experience was available to understand if a 96 general solution is needed, or where a more general solution is not 97 yet mature. An analysis of these requirements is documented in the 98 ETSI NGN Analysis ID [I-D.jesske-sipping-tispan-analysis]. For more 99 details about the assumptions made about these extensions, consult 100 the Applicability subsection for each extension. 102 3. Terminology 104 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 105 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 106 document, are to be interpreted as described in RFC 2119 [RFC2119]. 108 4. SIP Private Headers 110 4.1 The SIP P-AoC header field 112 This extension allows a User Agent Client (UAC) to request, at the 113 time of sending a request, that an Application Server provides 114 charging information related to the request where the header field is 115 included. The actual information to be delivered to the UAC is 116 outside the scope of this specification, but in general, it is 117 supposed to contain detailed information related to the session, 118 subscription, messaging or any other SIP request that may incur 119 charges to the user. 121 The scope of this document is limited to defining the header field 122 that provides a hint to an application server that the user is 123 willing to receive advice of charge information. The actual 124 mechanism and the contents of the advice of charging information 125 delivered to the user are outside the scope of this document, but as 126 an example, the application sender can send an instant message with 127 the advice of charge information, or the instant message can contain 128 a link to a web page that contains more detailed and accurate data. 129 The actual information to be delivered to the UAC is supposed to 130 contain detailed information related to the session, subscription, 131 messaging or any other SIP request that may incur charges to the 132 user, but once more, its acquisition and formatting is outside the 133 scope of this document. 135 The mechanism assumes that a SIP proxy is forwarding SIP requests 136 that contain the P-AoC header field to an application server that is 137 delivering the service. The application sever receives the request, 138 analyzes and process it, and based on the available information 139 produces the appropriate content and sends it in a separate request 140 to the user. The application server also forwards the request to its 141 destination. 143 4.1.1 Applicability statement of the P-AoC header field 145 This mechanism is appropriate in environments where a service 146 provider is collecting charging events related to the establishment 147 of SIP sessions, subscriptions, messages, and other related SIP 148 activities. Since SIP systems available in the public Internet will 149 typically not be subjected to this type of charging, this SIP 150 extension is not deemed to be of general interest. 152 4.1.2 Usage of the SIP P-AoC header field 154 When a User Agent (UA) generates a non-mid dialog request, and the 155 user wants to receive information about the potential charges 156 incurred by the SIP event, the UAC inserts a P-AoC header field in 157 the SIP request with the value set to 'inform'. The presence of this 158 header field in the request allows the network SIP proxies to route 159 the SIP request through an application server that can be analyzing 160 the request, collecting charging information, and generating some 161 sort of feedback to the user. 163 4.1.2.1 Procedures at the UA 165 A UAC that supports this extension and is willing to receive advice 166 of charge information related to the request MAY insert a P-AoC 167 header in a non mid-dialog request (e.g., initial INVITE, initial 168 SUBSCRIBE, MESSAGE outside a dialog, etc.). The presence of this 169 header is a request to the network to provide charging information, 170 if available, although there is not guarantee that the network nodes 171 are able or willing to honor the request for this information. 173 In general a User Agent Server (UAS) will not receive requests 174 containing a P-AoC header field. However, if the service is not 175 supported by the caller's network, then it is possible that the UAS 176 receives a SIP request containing a P-AoC header filed. User Agent 177 Servers that support this extension and receive a request that 178 contains a P-AoC header field SHOULD ignore the header field. 180 4.1.2.2 Procedures at a SIP proxy 182 Generally speaking, SIP proxies that receive a request containing a 183 P-AoC header field should include the header when the request is 184 forwarded downstream. Note that this is also the default proxy 185 behaviour for unknown header fields. 187 A SIP proxy that receives a request that includes a P-AoC header 188 field can route the request to an application server for further 189 analysis and generation of advice of charging information. Besides 190 that, SIP proxies do not do any other action on the header field. 192 4.1.2.3 Procedures at an application server 194 An application server that receives a SIP request that contains a 195 P-AoC header field MAY analyze the SIP request for the purpose of 196 collecting charging data. If the service is provided, the 197 application server SHOULD remove the P-AoC header field from the 198 request before forwarding downstream. But no matter whether the 199 service is provided or not the application server MUST forward the 200 request downstream. 202 Additionally, the application server can deliver the charging 203 information to the user, however, the nature and procedures of this 204 information is outside the scope of this memo. 206 4.1.3 Syntax of the P-AoC header field 208 The syntax of the P-AoC header field is described according to the 209 Augmented Backus-Naur Form (BNF) defined in RFC 2234 [RFC2234] and 210 extended by RFC 3261 [RFC3261]. 212 P-Advice-of-Charge = "P-AoC" HCOLON p-aoc-spec *(COMMA p-aoc-spec) 213 p-aoc-spec = "inform" / token *(SEMI aoc-param) 214 aoc-param = generic-param 216 The 'inform' value requests an application server to deliver 217 information of the potential charges associated with the request, and 218 at the same time request the application server to proceed processing 219 the request downstream. Other values or parameters can be added in 220 the future as needed. 222 4.1.4 Table of methods 224 Table 1 shows the occurance of the P-AoC header field in different 225 SIP methods. 227 Header field where proxy ACK BYE CAN INV OPT REG 228 ___________________________________________________________ 229 P-AoC R dr - - - o o o 231 Header field SUB NOT PRA INF UPD MSG REF 232 ___________________________________________________________ 233 P-AoC R o - - - - o o 235 Table 1: Summary of methods 237 4.2 Security Considerations 239 The presence of the P-AoC header in a request does not affect the 240 treatment of the request, and thus, the actions of rogue proxies that 241 deliberately insert or remove this header in SIP requests do not have 242 an action on the session, subscription, message, etc. itself. 244 4.3 IANA Considerations 246 This memo requests IANA to include a new P-AoC header field in the 247 Header Fields subregistry of the Session Initiation Protocol (SIP) 248 Parameters registry, as follows: 250 Header Name compact Reference 251 ----------------- ------- --------- 252 P-AoC [RFCXXXX] 254 Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 255 number of this memo. 257 4.4 Acknowledgements 259 The author would like to thank the members of the ETSI TISPAN WG3 for 260 their comments to this memo. 262 5. References 264 5.1 Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 270 Specifications: ABNF", RFC 2234, November 1997. 272 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 273 A., Peterson, J., Sparks, R., Handley, M., and E. 274 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 275 June 2002. 277 5.2 Informative References 279 [I-D.jesske-sipping-tispan-requirements] 280 Jesske, R., "Input Requirements for the Session Initiation 281 Protocol (SIP) in support for the European 282 Telecommunications Standards Institute (ETSI) Next 283 Generation Network (NGN) simulation services", 284 draft-jesske-sipping-tispan-requirements-01 (work in 285 progress), June 2005. 287 [I-D.jesske-sipping-tispan-analysis] 288 Jesske, R., "Analysis of the Input Requirements for the 289 Session Initiation Protocol (SIP) in support for the 290 European Telecommunications Standards Institute (ETSI) 291 Next Generation Networks (NGN) simulation service", 292 draft-jesske-sipping-tispan-analysis-00 (work in 293 progress), June 2005. 295 Author's Address 297 Miguel A. Garcia-Martin 298 Nokia 299 P.O. Box 407 300 NOKIA GROUP, FIN 00045 301 Finland 303 Phone: +358 50 480 4586 304 Email: miguel.an.garcia@nokia.com 306 Intellectual Property Statement 308 The IETF takes no position regarding the validity or scope of any 309 Intellectual Property Rights or other rights that might be claimed to 310 pertain to the implementation or use of the technology described in 311 this document or the extent to which any license under such rights 312 might or might not be available; nor does it represent that it has 313 made any independent effort to identify any such rights. Information 314 on the procedures with respect to rights in RFC documents can be 315 found in BCP 78 and BCP 79. 317 Copies of IPR disclosures made to the IETF Secretariat and any 318 assurances of licenses to be made available, or the result of an 319 attempt made to obtain a general license or permission for the use of 320 such proprietary rights by implementers or users of this 321 specification can be obtained from the IETF on-line IPR repository at 322 http://www.ietf.org/ipr. 324 The IETF invites any interested party to bring to its attention any 325 copyrights, patents or patent applications, or other proprietary 326 rights that may cover technology that may be required to implement 327 this standard. Please address the information to the IETF at 328 ietf-ipr@ietf.org. 330 Disclaimer of Validity 332 This document and the information contained herein are provided on an 333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 335 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 336 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 337 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Copyright Statement 342 Copyright (C) The Internet Society (2005). This document is subject 343 to the rights, licenses and restrictions contained in BCP 78, and 344 except as set forth therein, the authors retain all their rights. 346 Acknowledgment 348 Funding for the RFC Editor function is currently provided by the 349 Internet Society.