idnits 2.17.1 draft-ema-vpim-clid-09.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.5 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 575 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (May 2004) is 7278 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: 'FWS' is mentioned on line 243, but not defined == Missing Reference: 'RFC2806' is mentioned on line 286, but not defined ** Obsolete undefined reference: RFC 2806 (Obsoleted by RFC 3966) == Unused Reference: 'RFC 2806' is defined on line 417, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2806 (Obsoleted by RFC 3966) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VPIM Working Group Glenn Parsons 3 Internet Draft Janusz Maruszak 4 Document: Nortel Networks 5 Category: Standards Track May 2004 7 Calling Line Identification for Voice Mail Messages 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. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 This document describes a method for identifying the originating 29 calling party in the headers of a stored voice mail message. Two 30 new header fields are defined for this purpose: Caller_ID and 31 Called_Name. Caller_id is used to store sufficient information for 32 the recipient to callback, or reply to, the sender of the message. 33 Caller-name provides the name of the person sending the message. 35 Parsons & Maruszak Expires: 28/11/04 1 36 Calling Line Identification May 2004 38 Table of Contents 40 1. Introduction ....................................................3 41 2. Conventions used in this document ...............................3 42 3. Calling Line Identification Field ...............................4 43 3.1 Internal Call ..................................................4 44 3.2 External Call ..................................................4 45 3.3 Numbering Plan .................................................5 46 4. Caller Name Field ...............................................5 47 5. Formal Syntax ...................................................6 48 5.1 Calling Line Identification Syntax .............................6 49 5.2 Caller Name Syntax .............................................6 50 5.3 Examples .......................................................6 51 6. Other Considerations ............................................7 52 7. Security Considerations .........................................7 53 8. IANA Considerations ...........................................7 54 9. References ......................................................8 55 9.1 Normative References ...........................................8 56 9.2 Informative References .........................................8 57 10. Acknowledgments ................................................9 58 11. Author's Addresses .............................................9 59 11. Full Copyright Statement .......................................10 61 Parsons & Maruszak Expires: 28/11/04 2 62 Calling Line Identification May 2004 64 1. Introduction 66 There is currently a need for a mechanism to identify the 67 originating party of a voice mail message, outside of the "FROM" 68 header information. The telephone number and name of the caller are 69 typically available from the telephone network, but there is no 70 obvious header field to store this in an Internet Mail message. 72 This information is intended for use when the VPIM message format is 73 used for storing "Call Answer" voice messages in an Internet Mail 74 message store, i.e. the calling party leaves a voice message for the 75 recipient, who was unable to answer the call. The implication is 76 that no RFC 2822 address is known for the originator. 78 [VPIMV2R2] suggests the originating number be included as an 79 Internet address, using the first method shown below. There are 80 several other ways to store this information, but they all involve 81 some manipulation of the "From" field. For example: 83 1. From: "416 555 1234" 84 2. From: "John Doe" <4165551234@host> 85 3. From: unknown:; 87 Since any of these is a forced translation, it would be useful to 88 store the calling party's name and number as presented by the 89 telephone system to the called party without manipulation. This 90 would allow display of the calling party's information to the 91 recipient (similar to it appearing on the telephone) and also allow 92 future determination of an Internet address for the originator (if 93 one exists). Note that there is no requirement to store meta-data 94 (e.g., type of number, presentation restricted) as this information 95 is not presented to the called party and is generally not available 96 to voice mail systems. The intent is to store the information 97 available to an analog (non-ISDN) phone (e.g., per [T1.401] in North 98 America). 100 [RFC2076] currently lists "phone" as an Internet message header 101 which would hold the originating party's telephone number, but it is 102 listed as "non-standard", i.e. usage of this header is not generally 103 recommended. It also has no defined format, making the information 104 unparsable. There is no similar entry for the originator's name. 106 It is proposed that two new message header fields be included to 107 hold this information, namely the Calling Line Identification 108 ("Caller-ID"), and Caller Name ("Caller-Name"). 110 Parsons & Maruszak Expires: 28/11/04 3 111 Calling Line Identification May 2004 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 117 this document are to be interpreted as described in RFC-2119. 119 3. Calling Line Identification Field 121 The Calling Line Identification header ("Caller-ID") is to hold 122 sufficient information for the recipient's voice mail system to 123 call back, or reply to, the sender of the message. The number that 124 is contained in this header is supplied by the telephone system. 125 The exact format of the data received depends on the type of call, 126 that is -- internal or external call. 128 Note that for both options, the number field MUST contain only 129 the digits of the number and MUST be representable using the 130 American Standard Code for Information Interchange [ASCII] character 131 set; it does not include any separating character (e.g. "-"). 133 It is expected that default, and likely most common case, will not 134 have any numbering plan semantic associated with the number. 135 However, in the case that it is known, an optional "NumberingPlan" 136 parameter MAY be used to indicate the semantic. 138 3.1 Internal Call 140 For an internal call (e.g. between two extensions within the same 141 company), it is sufficient to relay only the extension of the 142 calling party, based on the company dialing plan. 144 However, the support of longer numbers may be supported by the 145 enterprise phone system. 147 3.2 External Call 149 For an international call, the calling party's number must be the 150 full international number as described in [E.164], i.e. Country Code 151 (CC), National Destination Code (NDC) and Subscriber Number (SN). 152 Other information, such as prefixes or symbols (e.g. "+"), MUST NOT 153 be included. [E.164] allows for numbers for up to 15 digits. 155 For a call within North America, it is also suggested to support 15 156 digits per [T1.625]. However, some service providers may only 157 support 10 digits as described in [T1.401] and [GR-31-CORE]. Though 158 it is desirable that an international number not be truncated to 10 159 digits if it contains more, it is recognized that this will happen 160 due to limitations of various systems. 162 Note that the other defined fields available to non-analog systems 163 (e.g., subaddress, redirecting number), as well as the meta-data, 164 are not intended to be stored in this header. 166 Parsons & Maruszak Expires: 28/11/04 4 167 Calling Line Identification May 2004 169 3.3 Numbering Plan 171 In this baseline case (i.e., analog lines), no numbering plan 172 information is known or implied. However, in the case that a 173 numbering plan is known, an optional "NumberingPlan" parameter MAY 174 be used to indicate the semantic. Only three semantics are defined- 175 "unknown", "local" and "e164". "unknown" is the default if no 176 numbering plan semantic is known (and the default if the parameter 177 is absent). "local" has meaning only within the domain of the voice 178 mail system that stored the message. That is, for example, the 179 voice mail system knows that the number belongs to a local numbering 180 plan. "e164" indicates that the number is as described in [E.164]. 181 "x-" may be used to indicate enterprise or service specific dialing 182 plans. 184 3.4 Date Header 186 The date and time may be included by the telephone system with the 187 calling party's telephone number per [T1.401]. This MAY be used, as 188 there is an existing "Date" Internet header to hold this information. 189 It is a local implementation decision whether this time or the local 190 system time be recorded in the "Date" header. 192 4. Caller Name Field 194 The name of the person sending the message is also important. 195 Information about whether the call is internal or external may be 196 included if it is available. This information may not be available 197 on international calls. 199 Further, the exact format for this field is typically a service 200 provider option per [T1.641]. It is possible for the caller's name 201 to be sent in one of several character sets depending on the service 202 provider signaling transport (e.g., ISDN-UP, SCCP, TCAP). These 203 include: 204 1) International Reference Alphabet (IRA), formerly know as 205 International Alphabet No.5 or IA5 [T.50] 206 2) Latin Alphabet No. 1 [8859-1] 207 3) American National Standard Code for Information Interchange 208 [ASCII] 209 4) Character Sets for the International Teletex Service [T.61] 211 Of these, the IRA and T.61 character set contains a number of 212 options that help specify national and application oriented 213 versions. If there is no agreement between parties to use these 214 options, then the 7-bit character set in which the graphical 215 characters of IRA, T.61 and ASCII are coded exactly the same, will 216 be assumed. Further, the 7-bit graphical characters of [8859-1] are 217 the same as in [ASCII]. 219 Note that for delivery to customer equipment in North America, the 220 calling name MUST be presented in ASCII per [T1.401]. 222 Parsons & Maruszak Expires: 16/08/04 5 223 Calling Line Identification May 2004 225 As a result, for the caller name header defined in this document, 226 characters are represented with ASCII characters. However, if a 227 name is received that cannot be represented in 7-bit ASCII, it MAY 228 be stored using its native character set as defined in [RFC2047]. 230 In telephone networks, the length of the name field MUST NOT exceed 231 50 characters, as defined in [T1.641]. However, service providers 232 may chose to limit this further to 15 characters for delivery to 233 customer equipment, e.g., [T1.401] and [GR-1188-CORE]. 235 5. Formal Syntax 237 Both Calling Line Identification and Caller Name follow the syntax 238 specification using the augmented Backus-Naur Form (BNF) as 239 described in [RFC2234]. While the semantics of these headers are 240 defined in sections 4 and 5, the syntax uses the 'unstructured' 241 token defined in [RFC2822]: 243 unstructured = *([FWS] utext) [FWS] 245 5.1 Calling Line Identification Syntax 247 "Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan=" 248 ( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF 250 ietf-token := 254 x-token := 257 5.2 Caller Name Syntax 259 "Caller-Name" ":" unstructured CRLF 261 5.3 Examples 263 To: +19725551212@vm1.example.com 264 Caller-ID: 6137684087 265 Caller-Name: Derrick Dunne 267 To: 6137637582@example.com 268 Caller-ID: 6139416900 269 Caller-Name: Jean Chretien 271 Parsons & Maruszak Expires: 16/08/04 6 272 Calling Line Identification May 2004 274 6. Other Considerations 276 6.1 Compatibility with other Internet phone numbers 278 The intent of these headers are to record without alteration or 279 interpretation the telephone number that is sent by the analog 280 phone system with an incoming call. If sufficient semantic is 281 known or can be infered, this may be included in the NumberingPlan 282 field. This may allow it to be later be translated into an 283 addressable phone number. Addressabe or dialable phone numbers 284 (which this document does not define) are defined in other 285 documents, such as GSTN address [RFC 3191] or telephone URL 286 [RFC2806]. 288 6.2 Usage 290 There are a few scenarios of how this mechanism may fail that must 291 be considered. The first is mentioned in section 3.2 - the 292 truncation of an international number to 10 digits. This could 293 result in a misinterpretation of the resulting number. For 294 instance, an international number (e.g., from Ireland) of the form 295 "353 91 73 3307" could be truncated to "53 91 73 3307" if received 296 in North America, and interpreted as "539 917 3307" - a seemingly 297 "North American" style number. Thus leaving the recipient with the 298 incorrect information to reply to the message _ and possibly with an 299 annoyed callee at the North American number. 301 The second scenario is the possibility of sending an internal 302 extension to an external recipient when a Call Answer message is 303 forwarded. This poses two problems, the recipient is given the 304 wrong phone number, and the company's dialing plan could be exposed. 306 The final concern deals with exercising character options that are 307 available in coding the Calling Name field. An international system 308 may send a message with coding options that are not available on the 309 receiving system. Thus giving the recipient an incorrect Caller 310 Name. 312 7. Security Considerations 314 Note that unlisted and restricted numbers are not a concern as these 315 header fields are defined to contain what the called party would see 316 (e.g., 'Private Name'), as opposed to the complete details exchanged 317 between service providers. 319 Parsons & Maruszak Expires: 16/08/04 7 320 Calling Line Identification May 2004 322 However, it must also be noted that this mechanism allows the 323 explicit indication of phone numbers in the headers of an email 324 message (used to store voice messages). While the rationale for 325 this is reviewed in section 1, the recipient of this message may not 326 be aware that this information is contained in the headers unless 327 the user's client presents the information. Its use is intended to 328 be informative as it is when it would appear on a telephone screen. 330 8. IANA Considerations 332 This document defines an IANA-administered registration space for 333 Caller-ID numbering plans in section 5.1. Each registry entry 334 consists of an identifying token and a short textual description of 335 the entry. There are three initial entries in this registry: 337 unknown - The number's semantics are unknown. This value is the 338 default in the absence of this parameter. 340 local - The number only has meaning within the domain of the 341 sending system identified by the RFC 2822 From field 342 of the message. 344 e164 - The number's semantics are described in [E.164]. 346 The only way to add additional entries (ietf-token in section 5.1) 347 to this registry is with a standards-track RFC. 349 9. References 351 9.1 Normative References 353 [VPIMV2R2] Vaudreuil, Greg, Parsons, Glenn, "Voice Profile for 354 Internet Mail, version 2", RFC 3801, June 2004. 356 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 357 Part Three: Message Header Extensions for Non-ASCII Text", 358 RFC 2047, November 1996 360 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, June 361 2001. 363 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 364 Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and 365 Demon Internet Ltd., November 1997 367 Parsons & Maruszak Expires: 28/11/04 8 368 Calling Line Identification May 2004 370 9.2 Informative References 372 [RFC2076] Palme, "Common Internet Message Headers", RFC 2076, 373 May 1997 375 [E.164] ITU-T Recommendation E.164 (1997), "The international public 376 telecommunication numbering plan" 378 [T.50] ITU-T Recommendation T.50 (1992), "International Reference 379 Alphabet (IRA)" 381 [T.61] CCITT Recommendation T.61 (1988) (Withdrawn), "Character 382 Repertoire and Coded Chaacter Sets for the International Teletex 383 Service" 385 [8859-1] ISO/IEC International Standard 8859-1 (1998), Information 386 Technology _ 8-bit single-byte coded graphic character sets _ 387 Part 1: Latin Alphabet No. 1 389 [ASCII] American National Standards Institute (ANSI), Coded 390 Character Set - 7-Bit American National Standard Code for 391 Information Interchange, ANSI X3.4, 1986. 393 [T1.401] American National Standards Institute (ANSI), 394 Telecommunications _ Network-to-Customer Installation Interfaces _ 395 Analog Voicegrade Switched Access Lines with Calling Number 396 Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator 397 Features, ANSI T1.6401.03-1998 399 [T1.625] American National Standards Institute (ANSI), 400 Telecommunications - Integrated Services Digital Network (ISDN) _ 401 Calling Line identification Presentation and Restriction 402 Supplementary Services, ANSI T1.625-1993 404 [T1.641] American National Standards Institute (ANSI), 405 Telecommunications - Calling Name Identification Presentation, ANSI 406 T1.641-1995 408 [GR-1188-CORE] Telcordia Technologies, "CLASS Feature: Calling Name 409 Delivery Generic Requirements", GR-1188-CORE, Issue 2, December 2000 411 [GR-31-CORE] Telcordia Technologies, "CLASS Feature: Calling Number 412 Delivery", GR-31-CORE, Issue 1, June 2000 414 [RFC 3191] Minimal GSTN address format in Internet Mail, RFC 3191, 415 Oct 2001 417 [RFC 2806] URL for Telephone Calls, RFC 2806, April 2000 419 Parsons & Maruszak Expires: 28/11/04 9 420 Calling Line Identification May 2004 422 10. Acknowledgments 424 The previous authors of drafts of this document were Derrick Dunne 425 and Jason Collins. The current authors would like to thank Derrick 426 and Jason for their contributions. 428 11. Author's Addresses 430 Glenn Parsons 431 Nortel Networks 432 P.O. Box 3511, Station C 433 Ottawa, ON K1Y 4H7 434 Phone: +1-613-763-7582 435 Email: gparsons@nortelnetworks.com 437 Janusz Maruszak 438 Phone: +1-416-885-0221 439 Email: jjmaruszak@sympatico.ca 441 12. Full Copyright Statement 443 Copyright (C) The Internet Society (2004). This document is subject 444 to the rights, licenses and restrictions contained in BCP 78, and 445 except as set forth therein, the authors retain all their rights. 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 450 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 451 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 452 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Intellectual Property 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at ietf- 477 ipr@ietf.org. 479 Acknowledgement 481 Funding for the RFC Editor function is currently provided by the 482 Internet Society. 484 Parsons & Maruszak Expires: 28/11/04 10