doc: Add RFC documents

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]
+