summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4715.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4715.txt')
-rw-r--r--doc/rfc/rfc4715.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4715.txt b/doc/rfc/rfc4715.txt
new file mode 100644
index 0000000..a253156
--- /dev/null
+++ b/doc/rfc/rfc4715.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group M. Munakata
+Request for Comments: 4715 S. Schubert
+Category: Informational T. Ohba
+ NTT
+ November 2006
+
+
+ The Integrated Services Digital Network (ISDN)
+ Subaddress Encoding Type for tel URI
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2006).
+
+Abstract
+
+ Without a tel URI parameter to carry an encoding type of Integrated
+ Services Digital Network (ISDN) subaddress, interworking between ISDN
+ User Part (ISUP) network and a Session Initiation Protocol (SIP)
+ network is impossible in some cases. To solve this problem, this
+ document specifies a new optional tel URI parameter to carry the
+ encoding type of ISDN subaddress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 1]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology .....................................................3
+ 3. Problem Statement ...............................................3
+ 3.1. SIP-ISDN Interconnection ...................................3
+ 3.2. ISDN-SIP-ISDN Interconnection ..............................4
+ 4. Requirements ....................................................5
+ 5. Parameter Definition ............................................6
+ 6. Usage ...........................................................6
+ 6.1. Gateway Behavior ...........................................7
+ 6.2. SIP Entity Behavior ........................................8
+ 7. Security Considerations .........................................9
+ 8. IANA Considerations .............................................9
+ 9. Acknowledgements ................................................9
+ 10. References ....................................................12
+ 10.1. Normative References .....................................12
+ 10.2. Informative References ...................................12
+
+1. Introduction
+
+ RFC 3966 [2] defines a tel URI parameter "isub" that is designed to
+ carry Integrated Services Digital Network (ISDN) subaddresses.
+
+ In an ISDN User Part (ISUP) message, a Network Service Access Point
+ (NSAP) address [6] or a "user specified" address can be carried as an
+ ISDN subaddress. The NSAP address accommodates various types of
+ address information along with an identifier for the address type and
+ its encoding type.
+
+ The "isub" parameter can carry any type of address, but RFC 3966 [2]
+ does not define a solution to carry information on a subaddress type
+ (whether the subaddress is NSAP or user specific) or an identifier
+ for the encoding type used.
+
+ The most commonly used encoding type for the ISDN subaddress is an
+ International Alphabet 5 (IA5) [5]. RFC 3966 does state, "ISDN
+ subaddresses typically contain IA5 characters but may contain any
+ octet value" considering this fact. Nevertheless, IA5 is just one of
+ the encoding types among various encoding types used in the NSAP
+ address. Therefore, "isub" parameter alone is not sufficient to
+ describe ISDN subaddresses, and additional information is needed.
+
+
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 2]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+ Lack of information describing the encoding type of ISDN
+ subaddress will make it difficult for an ISDN terminal receiving
+ the ISDN subaddress from the SIP network (SIP-ISDN
+ Interconnection) to interpret the "isub" parameter value, as a
+ gateway may translate it using a wrong encoding type and end up
+ with a wrong subaddress value due to inconsistency in the encoding
+ type used. It will also make it difficult to recover the original
+ ISDN subaddress value when an ISUP message is translated to a SIP
+ message and translated back to the ISUP message (ISDN-SIP-ISDN
+ Interconnection). As there is no placeholder to carry the
+ encoding type in the SIP message, the encoding type information
+ that was present in the original ISUP message will be lost, and
+ reconstructing the intended ISDN subaddress value is nearly
+ impossible.
+
+ To solve the issues presented, this specification defines an "isub-
+ encoding" parameter to carry information describing whether the value
+ of the "isub" parameter is an NSAP address as well as its encoding
+ type. In addition, this document specifies the accommodating values
+ to be carried in the "isub" parameter for each encoding type used.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+3. Problem Statement
+
+ Without a tel URI parameter to carry an encoding type of ISDN
+ subaddress, the problems described in Sections 3.1. and 3.2. might be
+ observed.
+
+3.1. SIP-ISDN Interconnection
+
+ The diagrams in Figure 1 show an issue that will be observed when
+ interworking between SIP network and ISDN network with an ISDN
+ subaddress. When SIP equipment sends a request with an "isub"
+ parameter to address an ISDN terminal behind Private Branch Exchange
+ (PBX), the encoding type of the ISDN subaddress currently cannot be
+ specified. Therefore, gateway sitting between the SIP network and
+ ISDN network cannot translate the value of "isub" into an ISUP
+ Initial Address Message (IAM) properly as the encoding type
+ information of the ISDN subaddress is missing.
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 3]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+ ISDN Terminal
+ +-----+
+ |--->| Bob |
+ SIP Network <---|---> ISDN | |12345|
+ | +-----+
+ SIP Equipment |
+ +-----+ +-----+ +----+ +-----+ | +-----+
+ |Alice|------->|Proxy|----->| GW |----->| PBX |----->|Carol|
+ +-----+ +-----+ +----+ +-----+ | +-----+
+ |
+ | +-----+
+ |--->|David|
+ +-----+
+
+
+ Alice Proxy GW Switch PBX Bob
+ | | | | | |
+ | INVITE | | | | |
+ |------------>| INVITE | | | |
+ | |------------>| IAM | | |
+ | | |----->|SETUP| |
+ | | | |---->| SETUP |
+ | | | | |---------->|
+ | | | | | |
+
+ Figure 1: SIP-ISDN Interconnection
+
+ INVITE tel:+17005554141;isub=12345 SIP/2.0
+
+ Note: SETUP is an ISDN message used between ISDN switch and
+ ISDN end terminal.
+
+3.2. ISDN-SIP-ISDN Interconnection
+
+ The diagrams in Figure 2 show an issue that will be observed when
+ interworking messages with an ISDN subaddress between two ISDN
+ networks that traverses through SIP networks. When an ISDN terminal
+ sends a message that contains an ISDN subaddress along with its
+ encoding type information, Gateway 1 translates the subaddress into
+ an "isub" parameter in a SIP message. However, its encoding type
+ information is dropped because there is no placeholder for the
+ encoding type in the SIP message. When Gateway 2 receives the
+ "isub", it cannot translate the value of the "isub" parameter back
+ into the IAM message properly because the encoding type information
+ of the ISDN subaddress is missing.
+
+
+
+
+
+
+Munakata, et al. Informational [Page 4]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+ ISDN Terminal
+ +-----+
+ |--->| Bob |
+ ISDN <---|---> SIP Network <---|---> ISDN | |12345|
+ | +-----+
+ ISDN Terminal |
+ +-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
+ |Alice|----->| GW1 |---->|Proxy|---->| GW2 |---->| PBX |----->|Carol|
+ +-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
+ |
+ | +-----+
+ |--->|David|
+ +-----+
+
+ Alice Switch GW1 Proxy GW2 Switch PBX Bob
+ | | | | | | | |
+ | SETUP | | | | | | |
+ |------>| IAM | | | | | |
+ | |---->| INVITE | | | | |
+ | | |---------->| INVITE | | | |
+ | | | |---------->| IAM | | |
+ | | | | |---->|SETUP| |
+ | | | | | |---->| SETUP |
+ | | | | | | |----------->|
+ | | | | | | | |
+
+ Figure 2: ISDN-SIP-ISDN Interconnection
+
+ INVITE tel:+17005554141;isub=12345 SIP/2.0
+
+4. Requirements
+
+ The followings are requirements for a solution to carry an ISDN
+ subaddress along with information of subaddress encoding type.
+
+ Req 1: When the "isub" parameter is present but no "isub-encoding"
+ parameter is present in a tel URI, the encoding of the ISDN
+ subaddress in the original message MUST be assumed to be IA5
+ (AFI=0x50).
+
+ Req 2: When using the "isub" parameters in tel URIs, the encoding
+ SHOULD be specified by using the optional "isub-encoding"
+ parameter unless the encoding of the ISDN subaddress is IA5
+ (AFI=0x50).
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 5]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+5. Parameter Definition
+
+ The parameter defined in this document is represented as a tel URI
+ parameter, which describes the encoding type information of the ISDN
+ subaddress. It is an optional parameter to tel URI to accommodate
+ some of the information lacking in the "isub" parameter defined in
+ RFC 3966 [2]. The ABNF [3] syntax is as follows.
+
+ isub-encoding = isub-encoding-tag "=" isub-encoding-value
+ isub-encoding-tag = "isub-encoding"
+ isub-encoding-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token
+
+ The semantics of these "isub-encoding" values are described below:
+
+ nsap-ia5: Indication that the "isub" parameter value needs to be
+ encoded using IA5 (AFI=0x50) when translated to an ISUP
+ message.
+
+ nsap-bcd: Indication that the "isub" parameter value needs to be
+ encoded using Binary Coded Decimal (BCD) (AFI=0x48) when
+ translated to an ISUP message.
+
+ nsap: Indication that the "isub" parameter value needs to be
+ encoded using the encoding type defined in ISO 8348 [6]
+ other than IA5 (AFI=0x50) or BCD (AFI=0x48).
+
+ Note: Q.931 [7] defines a "user specified" subaddress type, but
+ this document does not specify any behavior or value for
+ "user specified" subaddress type. Therefore, the "user
+ specified" subaddress is beyond the scope of this document.
+
+ An example of the syntax of the "isub-encoding" parameter (in a small
+ fragment of a SIP [4] message) is given below:
+
+ INVITE tel:+17005554141;isub=12345;isub-encoding=nsap-ia5 SIP/2.0
+ To: <tel:+17005554141;isub=12345;isub-encoding=nsap-ia5>
+ From: "Bob"<sip:bob@biloxi.example.com>;tag=1928301774
+
+6. Usage
+
+ It is anticipated that a tel URI parameter defined in this document
+ will be used along with an "isub" parameter defined in RFC 3966 [2]
+ when interworking between an ISUP network and a SIP network. The URI
+ parameter defined here is an optional parameter to the tel URI and is
+ useful only when it's accompanying the "isub" parameter.
+
+
+
+
+
+
+Munakata, et al. Informational [Page 6]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+ An ISDN subaddress information element carried in the ISUP message
+ consists of a 3-octet header followed by either an NSAP address or a
+ user-specified address. The NSAP address consists of an Initial
+ Domain Part (IDP) (Authority and Format Identifier (AFI) and
+ conditionally Initial Domain Identifier (IDI)) that identifies an
+ encoding type of the subaddress, and a Domain Specific Part (DSP)
+ that represents the subaddress value itself.
+
+ To find out more about the ISDN subaddress information element and
+ the NSAP address including definition of AFI, IDI, IDP, and DSP,
+ please refer to Appendices A and B.
+
+ If the "isub-encoding" is absent, and a message is interpreted by an
+ entity on the SIP network, the entity compliant to this specification
+ MUST assume that the original ISDN subaddress in an ISUP message was
+ an NSAP address with an encoding type of IA5 (AFI=0x50), of which the
+ DSP value was translated and set to the "isub" parameter value, and
+ MUST handle the message accordingly.
+
+ If the "isub-encoding" is absent, and the message is handled by a
+ gateway translating the SIP message to ISUP message, the gateway
+ compliant to this specification MUST encode the value in the "isub"
+ parameter using IA5 (AFI=0x50) and set the encoded value into the DSP
+ part of the NSAP address when translating the message into an ISUP
+ message.
+
+ If the value of "isub-encoding" is set to "nsap", the encoding type
+ (AFI) is assumed to be in the first two characters of the "isub"
+ parameter in hexadecimal represented as US-ASCII characters 0-9 and
+ A-F.
+
+ If the ISDN subaddress is not an NSAP address, the entity translating
+ the message SHOULD treat the message as if neither the "isub-
+ encoding" nor the "isub" parameters existed, unless it has a prior
+ knowledge of the encoding method used.
+
+ When an entity that is not compliant to this specification handles
+ the message with the "isub-encoding" parameter, it would simply
+ ignore the parameter and its value.
+
+6.1. Gateway Behavior
+
+ A gateway compliant to this specification that receives a message/
+ signal from an ISDN network containing an ISDN subaddress MUST check
+ the encoding used for the subaddress and MUST follow the procedures
+ given below.
+
+
+
+
+
+Munakata, et al. Informational [Page 7]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+ If the ISDN subaddress is an NSAP address encoded using IA5
+ (AFI=0x50), the entity MAY set the "isub-encoding" parameter to
+ the value "nsap-ia5" and set the DSP value of the NSAP address as
+ the value for the "isub" parameter using characters permitted for
+ the "isub" parameter as specified in RFC 3966 [2] or omit the
+ "isub-encoding" parameter.
+
+ If the ISDN subaddress is an NSAP address encoded using BCD
+ (AFI=0x48), the entity MUST set the "isub-encoding" parameter to
+ the value "nsap-bcd" and set the decoded DSP value of the NSAP
+ address as the value for the "isub" parameter in US-ASCII
+ characters using numbers.
+
+ Note: Each semi-octet should be translated into numbers (e.g.
+ 01011001 would be translated as 5 and 9).
+
+ If the ISDN subaddress is an NSAP address but is not encoded using
+ either IA5 (AFI=0x50) or BCD (AFI=0x48), the entity translating
+ the message MUST set the "isub-encoding" parameter to the value
+ "nsap" and the entire NSAP address as the value for the "isub"
+ parameter in hexadecimal represented as US-ASCII characters (0-9
+ and A-F).
+
+ If the ISDN subaddress is not an NSAP address, the entity
+ translating the message SHOULD NOT generate any "isub-encoding" or
+ "isub" parameters, unless it has a private agreement with the
+ recipient about what to do in this case.
+
+6.2. SIP Entity Behavior
+
+ An entity compliant to this specification setting an "isub" parameter
+ MUST follow the procedures given below.
+
+ If the ISDN subaddress is an NSAP address encoded using IA5
+ (AFI=0x50), the entity MAY set the "isub-encoding" to "nsap-ia5".
+ The "isub" parameter value MUST NOT exceed 19 characters. The
+ characters used MUST follow the syntax defined for the "isub"
+ parameter as specified in RFC 3966 [2].
+
+ If the ISDN subaddress is an NSAP address encoded using BCD
+ (AFI=0x48), the entity MUST set the "isub-encoding" to "nsap-bcd".
+ The "isub" parameter value MUST NOT exceed 38 US-ASCII characters
+ (numbers).
+
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 8]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+ If the ISDN subaddress is an NSAP address encoded using an
+ encoding type other than IA5 (AFI=0x50) or BCD (AFI=0x48), the
+ entity MUST set the "isub-encoding" to "nsap". The "isub"
+ parameter value MUST NOT exceed 40 US-ASCII characters and it MUST
+ be in hexadecimal represented as US-ASCII characters (0-9 and A-
+ F). The first two characters of the "isub" parameter MUST be the
+ encoding type (AFI) in this case.
+
+7. Security Considerations
+
+ The parameter defined here adds no new security considerations to
+ those discussed in RFC 3966 [2].
+
+8. IANA Considerations
+
+ This document requires no action by IANA.
+
+ Further information on a registry for tel parameters is covered in
+ [8].
+
+9. Acknowledgements
+
+ The authors thank John Elwell, James Rafferty, Steve Norreys, Michael
+ Hammer, Ray Forbes, Martin Dolly, Cullen Jennings, and Henning
+ Schulzrinne for providing extensive and constructive reviews and
+ feedback.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 9]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+Appendix A. Structure of an ISDN Subaddress Information Element
+
+ The structure of an ISDN subaddress information element in ISUP
+ messages is defined in Q.931 [7] as follows.
+
+ Bits
+ 8 7 6 5 4 3 2 1 Octets
+ +-----+-----------------------------------------+
+ | 0 | 1 1 1 0 0 0 0 | 1
+ +-----+-----------------------------------------+
+ | Length of called party subaddress contents | 2
+ +-----+-----------------------------------------+
+ | 1 | Subaddress type | o/e | 0 0 0 | 3
+ +-----+-----------------------------------------+
+ | | 4
+ | Subaddress information |
+ | |
+ | |
+ | |
+ +-----------------------------------------------+ max. 23
+
+ Figure 3: Structure of an ISDN Subaddress Information Element
+
+ Although the length varies, the maximum length of an ISDN subaddress
+ information element shown in the figure above is 23 octets. The
+ first 3 octets are the header. The rest of the octets comprise the
+ subaddress information that is either an NSAP address or a "user
+ specified" address.
+
+ The 1st octet is a called party subaddress information element
+ identifier that identifies that this information element is a called
+ party subaddress. The 2nd octet represents the length of called
+ party subaddress contents.
+
+ The 5th to 7th bits of the 3rd octet identify the type of subaddress.
+ This field is set to 0 0 0 when the subaddress is an NSAP address.
+ It is set to 0 1 0 when the subaddress is "user specified".
+
+ The 4th bit of the 3rd octet is an odd/even indicator. The odd/even
+ indicator is used when the type of subaddress is "user specified"
+ with the encoding type of BCD, to enable an entity to pad the missing
+ bits (last 4 bits of the subaddress information) when the number of
+ digits composing the subaddress is odd.
+
+ Note: When interworking with SIP, it is recommended not to
+ translate the padding bits to "isub" parameter.
+
+
+
+
+
+Munakata, et al. Informational [Page 10]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+Appendix B. Structure of NSAP Addresses
+
+ In ISUP messages, the ISDN subaddress is generally represented as an
+ NSAP address. The NSAP address is defined as follows in ISO 8348
+ [6].
+
+ The NSAP address consists of an Initial Domain Part (IDP) and a
+ Domain Specific Part (DSP). The IDP consists of two fields, an
+ Authority and Format Identifier (AFI) and an Initial Domain
+ Identifier (IDI). The maximum length of an NSAP address is 20
+ octets.
+
+ <------------------ NSAP Address ------------------>
+
+ +--------------------------------------------------+
+ | I D P | |
+ |-------------| D S P |
+ | AFI | IDI | |
+ +--------------------------------------------------+
+ 0 1 k ... Octets ... max. 20
+
+ Figure 4: Structure of NSAP Addresses
+
+ The AFI value is 2 hexadecimal digits (00-FF), and it identifies the
+ IDI format and the DSP syntax.
+
+ The IDI value when present is represented as decimal digits, and it
+ identifies a network addressing domain or authority responsible for
+ allocating values of the DSP. The length of IDI varies and depends
+ on the value of AFI.
+
+ The typical encoding type of the ISDN subaddress, IA5, is identified
+ as AFI=0x50. When the AFI value is 0x50, the length of IDI is zero;
+ therefore, the length of IDP is 2 digits (1 octet). In this case,
+ the DSP value is a subaddress encoded by IA5, and its maximum length
+ is 19 octets. The length of IDI is also zero when the encoding type
+ is BCD (AFI=0x48). The NSAP address for when the AFI value is set to
+ either 0x50 or 0x48 is shown below. As shown, DSP starts from the
+ 2nd octet of the NSAP address.
+
+ +--------------------------------------------------+
+ | IDP | |
+ |-----| D S P |
+ | AFI | |
+ +--------------------------------------------------+
+ 0 1 ... Octets ... max. 20
+
+ Figure 5 Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)
+
+
+
+Munakata, et al. Informational [Page 11]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+10. References
+
+10.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+ December 2004.
+
+ [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+10.2. Informative References
+
+ [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [5] International Telecommunication Union, "International Reference
+ Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) -
+ Information technology - 7-bit coded character set for
+ information interchange", Recommendation T.50, 1992.
+
+ [6] International Standard, "Information technology - Open Systems
+ Interconnection - Network service definition", ISO/IEC 8348,
+ 2002.
+
+ [7] International Telecommunication Union, "ISDN User-Network
+ Interface Layer 3 Specification for Basic Call Control",
+ Recommendation Q.931, 1998.
+
+ [8] Jennings, C. and V. Gurbani, "The Internet Assigned Numbers
+ Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
+ Registry", Work in Progress, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 12]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+Authors' Addresses
+
+ Mayumi Munakata
+ NTT Corporation
+
+ Phone: +81 422 36 7565
+ EMail: munakata.mayumi@lab.ntt.co.jp
+
+
+ Shida Schubert
+ NTT Corporation
+
+ Phone: +1 604 762 5606
+ EMail: shida@ntt-at.com
+
+
+ Takumi Ohba
+ NTT Corporation
+ 9-11, Midori-cho 3-Chome
+ Musashino-shi, Tokyo 180-8585
+ Japan
+
+ Phone: +81 422 59 7748
+ EMail: ohba.takumi@lab.ntt.co.jp
+ URI: http://www.ntt.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Munakata, et al. Informational [Page 13]
+
+RFC 4715 ISDN for tel URI November 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
+ AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+ THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
+ IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
+ PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Munakata, et al. Informational [Page 14]
+