idnits 2.17.1 draft-munakata-iptel-isub-type-04.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 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 60 lines 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 -- 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 (Jul 01, 2006) is 6508 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) ** Obsolete normative reference: RFC 4234 (ref. '3') (Obsoleted by RFC 5234) == Outdated reference: A later version (-06) exists of draft-ietf-iptel-tel-reg-02 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL M. Munakata 3 Internet-Draft S. Schubert 4 Expires: January 02, 2007 T. Ohba 5 NTT 6 Jul 01, 2006 8 ISDN subaddress encoding type for tel URI 9 draft-munakata-iptel-isub-type-04.txt 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 December 10, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Without a tel URI parameter to carry an encoding type of Integrated 43 Services Digital Network (ISDN) subaddress, interworking between ISDN 44 User Part (ISUP) network and a Session Initiation Protocol (SIP) 45 network is impossible in some cases. To solve this problem, this 46 document specifies a new optional tel URI parameter to carry the 47 encoding type of ISDN subaddress. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. SIP-ISDN Interconnection . . . . . . . . . . . . . . . . . 4 55 3.2. ISDN-SIP-ISDN Interconnection . . . . . . . . . . . . . . 6 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Parameter Definition . . . . . . . . . . . . . . . . . . . . . 7 58 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.1. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . 9 60 6.2. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 Appendix A. Structure of ISDN Subaddress Information Element . . 10 65 Appendix B. Structure of NSAP Addresses . . . . . . . . . . . . . 11 66 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13 69 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 RFC 3966 [2] defines a tel URI parameter "isub" that is designed to 76 carry Integrated Services Digital Network (ISDN) subaddresses. 78 In an ISDN User Part (ISUP) message, a Network Service Access Point 79 (NSAP) address [6] or a "user specified" address can be carried as 80 ISDN subaddress. The NSAP address accommodates various types of 81 address information along with an identifier for the address type and 82 its encoding type. 84 The "isub" parameter can carry any type of address but RFC 3966 [2] 85 doesn't define a solution to carry information of a subaddress type 86 (whether the subaddress is NSAP or User Specific) nor an identifier 87 for the encoding type used. 89 Most commonly used encoding type for the ISDN subaddress is an 90 International Alphabet 5 (IA5) [5]. RFC 3966 does state "ISDN 91 subaddresses typically contain IA5 characters but may contain any 92 octet value" considering this fact. Nevertheless, IA5 is just one of 93 the encoding types among various encoding types used in the NSAP 94 address. Therefore "isub" parameter alone is not enough to describe 95 ISDN subaddresses, and additional information is needed. 97 Lack of information describing the encoding type of ISDN 98 subaddress will make it difficult, for ISDN terminal receiving 99 ISDN subaddress from SIP network (SIP-ISDN Interconnection) to 100 interpret the "isub" parameter value, as a gateway may translate 101 it using a wrong encoding type and end up with a wrong subaddress 102 value due to inconsistency in the encoding type used. It will 103 also make it difficult to recover the original ISDN subaddress 104 value when an ISUP message is translated to a SIP message and 105 translated back to the ISUP message (ISDN-SIP-ISDN 106 Interconnection). As there is no placeholder to carry the 107 encoding type in the SIP message, the encoding type information 108 that was present in the original ISUP message will be lost and 109 reconstructing the intended ISDN subaddress value is nearly 110 impossible. 112 To solve the issues presented, this specification defines an "isub- 113 encoding" parameter to carry information describing whether the value 114 of "isub" parameter is an NSAP address as well as its encoding type. 115 In addition, this document specifies the accommodating values to be 116 carried in "isub" parameter for each encoding type used. 118 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [1]. 123 3. Problem Statement 125 Without a tel URI parameter to carry an encoding type of ISDN 126 subaddress, problems described in 3.1. and 3.2. would be observed. 128 3.1. SIP-ISDN Interconnection 130 The following diagrams show an issue that will be observed when 131 interworking between SIP network and ISDN network with an ISDN 132 subaddress. When SIP equipment sends a request with "isub" parameter 133 to address an ISDN terminal behind Private Branch Exchange (PBX), the 134 encoding type of the ISDN subaddress currently can not be specified. 135 Therefore gateway sitting between SIP network and ISDN network can 136 not translate the value of "isub" into an ISUP Initial Address 137 Message (IAM) properly as the encoding type information of the ISDN 138 subaddress is missing. 140 ISDN Terminal 141 +-----+ 142 |--->| Bob | 143 SIP Network <---|---> ISDN | |12345| 144 | +-----+ 145 SIP Equipment | 146 +-----+ +-----+ +----+ +-----+ | +-----+ 147 |Alice|------->|Proxy|----->| GW |----->| PBX |----->|Carol| 148 +-----+ +-----+ +----+ +-----+ | +-----+ 149 | 150 | +-----+ 151 |--->|David| 152 +-----+ 154 Alice Proxy GW Switch PBX Bob 155 | | | | | | 156 | INVITE | | | | | 157 |------------>| INVITE | | | | 158 | |------------>| IAM | | | 159 | | |----->|SETUP| | 160 | | | |---->| SETUP | 161 | | | | |---------->| 162 | | | | | | 164 Figure 1: SIP-ISDN Interconnection 166 INVITE tel:+17005554141;isub=12345 SIP/2.0 168 Note: SETUP is an ISDN message used between ISDN switch and 169 ISDN end terminal. 171 3.2. ISDN-SIP-ISDN Interconnection 173 The following diagrams show an issue that will be observed when 174 interworking messages with an ISDN subaddress between two ISDN 175 networks that traverses through SIP networks. When an ISDN terminal 176 sends a message that contains ISDN subaddress along with its encoding 177 type information, Gateway 1 translates the subaddress into "isub" 178 parameter in a SIP message. However, its encoding type information 179 is dropped because there is no placeholder for the encoding type in 180 the SIP message. When Gateway 2 receives "isub", it can not 181 translate the value of "isub" parameter back into IAM message 182 properly because the encoding type information of the ISDN subaddress 183 is missing. 185 ISDN Terminal 186 +-----+ 187 |--->| Bob | 188 ISDN <---|---> SIP Network <---|---> ISDN | |12345| 189 | +-----+ 190 ISDN Terminal | 191 +-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ 192 |Alice|----->| GW1 |---->|Proxy|---->| GW2 |---->| PBX |----->|Carol| 193 +-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ 194 | 195 | +-----+ 196 |--->|David| 197 +-----+ 199 Alice Switch GW1 Proxy GW2 Switch PBX Bob 200 | | | | | | | | 201 | SETUP | | | | | | | 202 |------>| IAM | | | | | | 203 | |---->| INVITE | | | | | 204 | | |---------->| INVITE | | | | 205 | | | |---------->| IAM | | | 206 | | | | |---->|SETUP| | 207 | | | | | |---->| SETUP | 208 | | | | | | |----------->| 209 | | | | | | | | 211 Figure 2: ISDN-SIP-ISDN Interconnection 213 INVITE tel:+17005554141;isub=12345 SIP/2.0 215 4. Requirements 217 The followings are requirements for a solution to carry an ISDN 218 subaddress along with information of subaddress encoding type. 220 Req 1: When "isub" parameter is present but no "isub-encoding" 221 parameter is present in a tel URI, the encoding of the ISDN 222 subaddress in the original message MUST be assumed to be IA5 223 (AFI=0x50). 224 Req 2: When using "isub" parameters in tel URIs, the encoding SHOULD 225 be specified by using the optional "isub-encoding" parameter 226 unless the encoding of ISDN subaddress is IA5 (AFI=0x50). 228 5. Parameter Definition 230 The parameter defined in this draft is represented as a tel URI 231 parameter, which describes the encoding type information of the ISDN 232 subaddress. It is an optional parameter to tel URI to accommodate 233 some of the information lacking in the "isub" parameter defined in 234 RFC 3966 [2]. The ABNF [3] syntax is as follows. 236 isub-encoding = isub-encoding-tag "=" isub-encoding-value 237 isub-encoding-tag = "isub-encoding" 238 isub-encoding-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token 240 The semantics of these "isub-encoding" values are described below: 242 nsap-ia5: Indication that the "isub" parameter value needs to be 243 encoded using IA5 (AFI=0x50) when translated to an ISUP 244 message. 246 nsap-bcd: Indication that the "isub" parameter value needs to be 247 encoded using Binary Coded Decimal (BCD) (AFI=0x48) when 248 translated to the ISUP message. 250 nsap: Indication that the "isub" parameter value needs to be 251 encoded using encoding type defined in ISO8348[6] 252 other than IA5 (AFI=0x50) or BCD (AFI=0x48). 254 Note: Q.931 [7] defines an "user specified" subaddress type, but 255 this document does not specify any behavior or value for "user 256 specified" subaddress type. Therefore, the "user specified" 257 subaddress is beyond the scope of this document. 259 An example of the syntax of the "isub-encoding" parameter (in a small 260 fragment of a SIP [4] message) is given below: 262 INVITE tel:+17005554141;isub=12345;isub-encoding=nsap-ia5 SIP/2.0 263 To: 264 From: "Bob";tag=1928301774 266 6. Usage 268 It is anticipated that a tel URI parameter defined in this document 269 will be used along with an "isub" parameter defined in RFC 3966 [2] 270 when interworking between an ISUP networks and a SIP network. The 271 URI parameter defined here is an optional parameter to the tel URI, 272 and is useful only when it's accompanying the "isub" parameter. 274 An ISDN subaddress information element carried in the ISUP message 275 consists of 3-octet header followed by either an NSAP address or a 276 user specified address. The NSAP address consists of an IDP (AFI and 277 conditionally IDI) that identifies an encoding type of the 278 subaddress, and a DSP that represents the subaddress value itself. 280 To find out more about the ISDN subaddress information element and 281 the NSAP address including definition of AFI, IDI, IDP, and DSP, 282 please reference the Appendices A and B. 284 If the "isub-encoding" is absent, and a message is interpreted by an 285 entity on the SIP network, the entity compliant to this specification 286 MUST assume that the original ISDN subaddress in ISUP message was an 287 NSAP address with an encoding type of IA5 (AFI=0x50), of which DSP 288 value was translated and set to "isub" parameter value and MUST 289 handle the message accordingly. 291 If the "isub-encoding" is absent, and the message is handled by a 292 gateway translating the SIP message to ISUP message, the gateway 293 compliant to this specification MUST encode the value in the "isub" 294 parameter using IA5 (AFI=0x50), and set the encoded value into the 295 DSP part of the NSAP address when translating the message into ISUP 296 message. 298 If the value of "isub-encoding" is set to "nsap", the encoding type 299 (AFI) is assumed to be in the first two characters of "isub" 300 parameter in hexadecimal represented as US-ASCII characters 0-9 and 301 A-F. 303 If the ISDN subaddress is not an NSAP address, the entity 304 translating the message SHOULD treat the message as if neither 305 "isub-encoding" nor "isub" parameters existed, unless it has a 306 prior knowledge of the encoding method used. 308 When an entity that is not compliant to this specification handles 309 the message with the "isub-encoding" parameter, it would simply 310 ignore the parameter and its value. 312 6.1. Gateway Behavior 314 Gateway compliant to this specification that receives message/signal 315 from ISDN network containing ISDN subaddress MUST check the encoding 316 used for the subaddress and MUST follow the procedures given below. 318 If the ISDN subaddress is an NSAP address encoded using IA5 319 (AFI=0x50), the entity MAY set the "isub-encoding" parameter to 320 the value "nsap-ia5" and set the DSP value of the NSAP address as 321 the value for "isub" parameter using characters permitted for 322 "isub" parameter as specified in RFC 3966 [2] or omit the 323 "isub-encoding" parameter. 325 If the ISDN subaddress is an NSAP address encoded using BCD 326 (AFI=0x48), the entity MUST set the "isub-encoding" parameter to 327 the value "nsap-bcd" and set the decoded DSP value of the NSAP 328 address as the value for "isub" parameter in US-ASCII characters 329 using numbers. 331 Note: Each semi-octet should be translated into numbers. e.g.) 332 01011001 would be translated as 5 and 9. 334 If the ISDN subaddress is an NSAP address but neither encoded 335 using IA5 (AFI=0x50) nor BCD (AFI=0x48), the entity translating 336 the message MUST set the "isub-encoding" parameter to the value 337 "nsap" and the entire NSAP address as the value for "isub" 338 parameter in hexadecimal represented as US-ASCII characters (0-9 339 and A-F). 341 If the ISDN subaddress is not an NSAP address, the entity 342 translating the message SHOULD NOT generate any "isub-encoding" 343 or "isub" parameters, unless it has a private agreement with the 344 recipient about what to do in this case. 346 6.2. SIP Entity Behavior 348 An entity compliant to this specification setting an "isub" parameter 349 MUST follow the procedures given below. 351 If the ISDN subaddress is an NSAP address encoded using IA5 352 (AFI=0x50), the entity MAY set the "isub-encoding" to "nsap-ia5". 353 The "isub" parameter value MUST NOT exceed 19 characters. The 354 characters used MUST follow the syntax defined for "isub" 355 parameter as specified in RFC 3966 [2] 356 If the ISDN subaddress is an NSAP address encoded using BCD 357 (AFI=0x48), the entity MUST set the "isub-encoding" to "nsap-bcd". 358 The "isub" parameter value MUST NOT exceed 38 US-ASCII characters 359 (numbers). 361 If the ISDN subaddress is an NSAP address encoded using other than 362 IA5 (AFI=0x50) or BCD (AFI=0x48), the entity MUST set the "isub- 363 encoding" to "nsap". The "isub" parameter value MUST NOT exceed 364 40 US-ASCII characters and it MUST be in hexadecimal represented 365 as US-ASCII characters (0-9 and A-F). 367 7. Security Considerations 369 The parameter defined here adds no new security considerations to 370 those discussed in RFC 3966 [2]. 372 8. IANA Considerations 374 This document requires no action by IANA. 376 Further information on a registry for tel parameters is covered in 377 [8] 379 9. Acknowledgements 381 John Elwell, James Rafferty, Steve Norreys, Michael Hammer, Ray 382 Forbes, Martin Dolly, Cullen Jennings and Henning Schulzrinne for 383 providing extensive and constructive reviews and feedbacks. 385 Appendix A. Structure of ISDN Subaddress Information Element 387 The structure of ISDN subaddress information element in ISUP messages 388 is defined in Q.931 [7] as follows. 390 Bits 391 8 7 6 5 4 3 2 1 Octets 392 +-----+-----------------------------------------+ 393 | 0 | 1 1 1 0 0 0 0 | 1 394 +-----+-----------------------------------------+ 395 | Length of called party subaddress contents | 2 396 +-----+-----------------------------------------+ 397 | 1 | Subaddress type | o/e | 0 0 0 | 3 398 +-----+-----------------------------------------+ 399 | | 4 400 | Subaddress information | 401 | | 402 | | 403 | | 404 +-----------------------------------------------+ max. 23 406 Figure 3: Structure of ISDN Subaddress Information Element 408 Although the length varies, the maximum length of an ISDN subaddress 409 information element shown in the figure above is 23 octets. The 410 first 3 octets are header. The rest of the octets comprise the 411 subaddress information that is either an NSAP address or a "user 412 specified" address. 414 The 1st octet is a called party subaddress information element 415 identifier that identifies that this information element is a called 416 party subaddress. The 2nd octet represents the length of called 417 party subaddress contents. 419 The 5th to 7th bits of the 3rd octet identifies the type of 420 subaddress. This field is set to 0 0 0 when the subaddress is an 421 NSAP address. It is set to 0 1 0 when the subaddress is "user 422 specified". 424 The 4th bit of the 3rd octet is an odd/even indicator. The odd/even 425 indicator is used when the type of subaddress is "user specified" 426 with the encoding type of BCD, to enable an entity to pad the missing 427 bits (last 4bits of subaddress information) when the numbers of 428 digits composing subaddress is odd. 430 Note: When interworking with SIP it is recommended not to 431 translate the padding bits to "isub" parameter. 433 Appendix B. Structure of NSAP Addresses 434 In ISUP messages, the ISDN subaddress is generally represented as an 435 NSAP address. The NSAP address is defined as follows in ISO 8348 436 [6]. 438 The NSAP address consists of an Initial Domain Part (IDP) and a 439 Domain Specific Part (DSP). The IDP consists of two fields, an 440 Authority and Format Identifier (AFI) and an Initial Domain 441 Identifier (IDI). The maximum length of NSAP address is 20 octets. 443 <------------------ NSAP Address ------------------> 445 +--------------------------------------------------+ 446 | I D P | | 447 |-------------| D S P | 448 | AFI | IDI | | 449 +--------------------------------------------------+ 450 0 1 k ... Octets ... max. 20 452 Figure 4: Structure of NSAP Addresses 454 The AFI value is two hexadecimal digits (00-FF), and it identifies 455 the IDI format and the DSP syntax. 457 The IDI value when present is represented as decimal digits, and it 458 identifies a network addressing domain or authority responsible for 459 allocating values of the DSP. The length of IDI varies and it 460 depends on the value of AFI. 462 Typical encoding type of the ISDN subaddress, IA5, is identified as 463 AFI=0x50. When AFI value is 0x50, the length of IDI is zero, 464 therefore the length of IDP is 2 digits (1 octet). In this case, DSP 465 value is a subaddress encoded by IA5 and its maximum length is 19 466 octets. The length of IDI is also zero when the encoding type is BCD 467 (AFI=0x48). The NSAP address for when AFI's value set to either 0x50 468 or 0x48 is shown below. As shown, DSP starts from the 2nd octet of 469 the NSAP address. 471 +--------------------------------------------------+ 472 | IDP | | 473 |-----| D S P | 474 | AFI | | 475 +--------------------------------------------------+ 476 0 1 ... Octets ... max. 20 478 Figure 5 Structure of NSAP Addresses (AFI=0x50 or AFI=0x48) 480 Appendix C. Change Log 482 Changes from 00 to 01. - Many editorial fixes and grammatical 483 correction. - Added a text on "User-Specific" address type. - Added a 484 text on "odd/even" indicator. - Changed the requirements to clearly 485 address the requirements this draft is trying to meet. 487 Changes from 01 to 02. - GEN-ART provided some constructive feedbacks 488 and we reflected some of the recommended changes. 489 1. Some of the SHOULD were changed to MUST to hold a better 490 compatibility with the pre-existing implementation. 491 2. Fixed numerical grammatical errors. 492 3. Added an appendix to explain the ISDN subaddress information 493 element. 494 4. Expanded the appendix on NSAP address structure to clarify some 495 of the ambiguity that was addressed. 496 5. Clarified some of the text on entity behaviors.(Section 6) 498 Changes from 02 to 03. - Reflected comments provided by IESG. 499 1. parameter defined in this draft was renamed from "isub-type" to 500 "isub-encoding". 501 2. Added a reference to a draft handling the IANA registration. 503 10. References 505 10.1. Normative Reference 507 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 508 Levels", BCP 14, RFC 2119, March 1997. 510 [2] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 511 December 2004. 513 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 514 Specifications: ABNF", RFC 4234, October 2005. 516 10.2. Informative Reference 518 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 519 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 520 Session Initiation Protocol", RFC 3261, June 2002. 522 [5] International Telecommunications Union, "International Reference 523 Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - 524 Information technology - 7-bit coded character set for 525 information interchange", Recommendation T.50, 1992. 527 [6] INTERNATIONAL STANDARD, "Information technology - Open Systems 528 Interconnection - Network service definition", ISO/IEC 8348. 530 [7] INTERNATIONAL Telecommunications Union, "ISDN User-Network 531 Interface Layer 3 Specification for Basic Call Control", 532 Recommendation Q.931, 1998. 534 [8] Jennings, C. and V. Gurbani, "The Internet Assigned Number 535 Authority (IANA) tel Uniform Resource Identifier (URI) Parameter 536 Registry", draft-ietf-iptel-tel-reg-02.txt, May 2006. 538 Authors' Addresses 540 Mayumi Munakata 541 NTT Corporation 543 Phone: +81 422 36 7565 544 Email: munakata.mayumi at lab.ntt.co.jp 546 Shida Schubert 547 NTT Corporation 549 Phone: +1 604 762 5606 550 Email: shida at ntt-at.com 552 Takumi Ohba 553 NTT Corporation 554 9-11, Midori-cho 3-Chome 555 Musashino-shi, Tokyo 180-8585 556 Japan 558 Phone: +81 422 59 7748 559 Email: ohba.takumi at lab.ntt.co.jp 560 URI: http://www.ntt.co.jp 562 Intellectual Property Statement 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org. 586 Disclaimer of Validity 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 591 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 592 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 593 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Copyright Statement 598 Copyright (C) The Internet Society (2006). This document is subject 599 to the rights, licenses and restrictions contained in BCP 78, and 600 except as set forth therein, the authors retain all their rights. 602 Acknowledgment 604 Funding for the RFC Editor function is currently provided by the 605 Internet Society.