idnits 2.17.1 draft-peterson-tel-cpc-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 (October 27, 2002) is 7851 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) == Unused Reference: '3' is defined on line 166, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2806 (ref. '1') (Obsoleted by RFC 3966) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2543 (ref. '3') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: April 27, 2003 October 27, 2002 6 The Calling Party's Category tel URL Parameter 7 draft-peterson-tel-cpc-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 27, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document specifies a new parameter for the tel URL [1] that 39 represents the Calling Party's Category, a parameter used in SS7 ISUP 40 [2] signaling. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Parameter Definition . . . . . . . . . . . . . . . . . . . . . . 3 46 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 48 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 49 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 51 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6 53 1. Introduction 55 ISUP defines a Calling Party's Category (CPC) parameter that 56 characterizes the station used to originate a call and carries other 57 important state that can describe the originating party. When 58 telephone numbers are contained in URLs, such as the tel URL, it may 59 be desirable to communicate any CPC associated with that telephone 60 number or, in the context of a call, the party calling from it. 62 Note that in some networks (including North America), the Originating 63 Line Information (OLI) parameter is used to carry this information in 64 ISUP rather than the CPC parameter. Legacy multifrequency (MF) 65 signaling networks carry this information in the ANI II Digits. The 66 tel URL parameter specified in this document is designed to carry 67 data from these sources as well. 69 2. Parameter Definition 71 The Calling Party's Category is represented as a tel URL parameter. 72 The ABNF syntax is as follows: 74 cpc = cpc-tag "=" cpc-value 75 cpc-tag = "cpc" 76 cpc-value = string 78 CPC values (``cpc-value'' strings) must be registered with IANA. The 79 following values are pre-registered by this document: 81 ordinary: The caller has been identified, and has no special 82 features. 84 priority: This call has priority/emergency status. 86 data: This call will contain voice-band data. 88 test: This is a test call that has been originated as part of a 89 maintenance procedure. 91 operator: The call was generated by an operator position. 93 payphone: The calling station is a payphone. 95 prison: The calling station is in a prison. 97 unknown: The CPC could not be ascertained. 99 An example of the syntax of the CPC parameter (in a small fragment of 100 a SIP message) is given below: 102 INVITE sip:bob@biloxi.com SIP/2.0 103 To: "Bob" 104 From: ;tag=1928301774 106 3. Usage 108 The CPC is generally useful only when describing the originator of a 109 telephone call. Therefore, when this parameter is used in an 110 application such as SIP, it is recommended that the parameter be 111 applied to URLs that characterize the originator of a call (such as a 112 SIP URI or tel URL in the From header field of a SIP message). 114 It is anticipated that this URL will be used primarily by gateways 115 that interwork ISUP networks with SIP networks. Various SIP network 116 intermediaries might consult the CPC as they make routing decisions, 117 although no specific behavior is prescribed in this document. While 118 no specific mapping of the various ISUP parameters that contain CPC 119 data is offered in this document, creating such a mapping would be 120 trivial. 122 If the CPC parameter is not present, consumers of the CPC should 123 treat the URL as if it specified a CPC of "unknown". 125 Generally, only one instance of the CPC will be associated with a 126 particular URL. 128 4. Security Considerations 130 The information contained in the CPC parameter may be of a private 131 nature, and it may not be appropriate for this value to be revealed 132 to the destination user (typically it would not be so revealed in the 133 PSTN). 135 Otherwise, this mechanism adds no new security considerations to 136 those discussed in RFC2806 [1]. 138 5. IANA Considerations 140 This document requests the creation of an IANA registry for Calling 141 Party's Category values. The values of the CPC parameter in use in 142 ISUP are unfortunately quite specific to national networks, and thus 143 it is very difficult to uncover all the usages that may be in place 144 in various networks. Note that in North American networks, the 145 Originating Line Information parameter contains information common 146 found in the Calling Party's Category elsewhere; it is therefore 147 legitimate to register values associated with the Originating Line 148 Information in this registry. 150 In order to file a registration, interested parties must contact IANA 151 and supply them with both a new ``cpc-value'' and a short reason 152 phrase describing the usage of the new CPC. Some values are given in 153 Section 2; we ask that these values be pre-registered upon 154 publication of this document as an RFC. It is not expected that this 155 registry will require any expert supervision. 157 References 159 [1] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 160 2000. 162 [2] International Telecommunications Union, "Recommendation Q.763: 163 Signalling System No. 7: ISDN user part formats and codes", 164 September 1997, . 166 [3] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 167 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 169 Author's Address 171 Jon Peterson 172 NeuStar, Inc. 173 1800 Sutter St 174 Suite 570 175 Concord, CA 94520 176 US 178 Phone: +1 925/363-8720 179 EMail: jon.peterson@neustar.biz 180 URI: http://www.neustar.biz/ 182 Full Copyright Statement 184 Copyright (C) The Internet Society (2002). All Rights Reserved. 186 This document and translations of it may be copied and furnished to 187 others, and derivative works that comment on or otherwise explain it 188 or assist in its implementation may be prepared, copied, published 189 and distributed, in whole or in part, without restriction of any 190 kind, provided that the above copyright notice and this paragraph are 191 included on all such copies and derivative works. However, this 192 document itself may not be modified in any way, such as by removing 193 the copyright notice or references to the Internet Society or other 194 Internet organizations, except as needed for the purpose of 195 developing Internet standards in which case the procedures for 196 copyrights defined in the Internet Standards process must be 197 followed, or as required to translate it into languages other than 198 English. 200 The limited permissions granted above are perpetual and will not be 201 revoked by the Internet Society or its successors or assigns. 203 This document and the information contained herein is provided on an 204 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 205 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 206 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 207 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 208 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 210 Acknowledgement 212 Funding for the RFC Editor function is currently provided by the 213 Internet Society.