[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4715

IPTEL                                                        M. Munakata
Internet-Draft                                               S. Schubert
Expires: December 10, 2006                                       T. Ohba
                                                                     NTT
                                                            Jun 08, 2006


               ISDN subaddress encoding type for tel URI
                 draft-munakata-iptel-isub-type-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (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.        Expires December 10, 2006               [Page 1]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  SIP-ISDN Interconnection . . . . . . . . . . . . . . . . .  4
     3.2.  ISDN-SIP-ISDN Interconnection  . . . . . . . . . . . . . .  6
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Parameter Definition . . . . . . . . . . . . . . . . . . . . .  7
   6.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Gateway Behavior . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  SIP Entity Behavior  . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Structure of ISDN Subaddress Information Element  . . 10
   Appendix B.  Structure of NSAP Addresses . . . . . . . . . . . . . 11
   Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative Reference  . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative Reference  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16




























Munakata, et al.        Expires December 10, 2006               [Page 2]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


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
   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]
   doesn't define a solution to carry information of a subaddress type
   (whether the subaddress is NSAP or User Specific) nor an identifier
   for the encoding type used.

   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 enough to describe
   ISDN subaddresses, and additional information is needed.

      Lack of information describing the encoding type of ISDN
      subaddress will make it difficult, for ISDN terminal receiving
      ISDN subaddress from 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 "isub" parameter is an NSAP address as well as its encoding type.
   In addition, this document specifies the accommodating values to be
   carried in "isub" parameter for each encoding type used.


2.  Terminology




Munakata, et al.        Expires December 10, 2006               [Page 3]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


   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, problems described in 3.1. and 3.2. would be observed.

3.1.  SIP-ISDN Interconnection

   The following diagrams 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 "isub" parameter
   to address an ISDN terminal behind Private Branch Exchange (PBX), the
   encoding type of the ISDN subaddress currently can not be specified.
   Therefore gateway sitting between SIP network and ISDN network can
   not 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.        Expires December 10, 2006               [Page 4]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 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.

















Munakata, et al.        Expires December 10, 2006               [Page 5]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


3.2.  ISDN-SIP-ISDN Interconnection

   The following diagrams 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 ISDN subaddress along with its encoding
   type information, Gateway 1 translates the subaddress into "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 "isub", it can not
   translate the value of "isub" parameter back into IAM message
   properly because the encoding type information of the ISDN subaddress
   is missing.



                                                           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




Munakata, et al.        Expires December 10, 2006               [Page 6]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


4.  Requirements

   The followings are requirements for a solution to carry an ISDN
   subaddress along with information of subaddress encoding type.

   Req 1:  When "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 "isub" parameters in tel URIs, the encoding SHOULD
           be specified by using the optional "isub-encoding" parameter
           unless the encoding of ISDN subaddress is IA5 (AFI=0x50).


5.  Parameter Definition

   The parameter defined in this draft 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 the ISUP message.

   nsap:     Indication that the "isub" parameter value needs to be
             encoded using encoding type defined in ISO8348[6]
             other than IA5 (AFI=0x50) or BCD (AFI=0x48).









Munakata, et al.        Expires December 10, 2006               [Page 7]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


      Note: Q.931 [7] defines an "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 networks 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.

   An ISDN subaddress information element carried in the ISUP message
   consists of 3-octet header followed by either an NSAP address or a
   user specified address.  The NSAP address consists of an IDP (AFI and
   conditionally IDI) that identifies an encoding type of the
   subaddress, and a 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 reference the 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 ISUP message was an
   NSAP address with an encoding type of IA5 (AFI=0x50), of which DSP
   value was translated and set to "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 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 "isub"
   parameter in hexadecimal represented as US-ASCII characters 0-9 and



Munakata, et al.        Expires December 10, 2006               [Page 8]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


   A-F.

   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

   Gateway compliant to this specification that receives message/signal
   from ISDN network containing ISDN subaddress MUST check the encoding
   used for the subaddress and 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" parameter to
      the value "nsap-ia5" and set the DSP value of the NSAP address as
      the value for "isub" parameter using characters permitted for
      "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" parameter to
      the value "nsap-bcd" and set the decoded DSP value of the NSAP
      address as the value for "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 neither encoded
      using IA5 (AFI=0x50) nor 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 "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
      "isub-encoding" nor "isub" parameters existed, unless it has a
      prior knowledge of the encoding method used.

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 "isub"
      parameter as specified in RFC 3966 [2]


Munakata, et al.        Expires December 10, 2006               [Page 9]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


      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).

      If the ISDN subaddress is an NSAP address encoded using 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).


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

   John Elwell, James Rafferty, Steve Norreys, Michael Hammer, Ray
   Forbes, Martin Dolly, Cullen Jennings and Henning Schulzrinne for
   providing extensive and constructive reviews and feedbacks.


Appendix A.  Structure of ISDN Subaddress Information Element

   The structure of ISDN subaddress information element in ISUP messages
   is defined in Q.931 [7] as follows.














Munakata, et al.        Expires December 10, 2006              [Page 10]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


                                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 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 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 identifies 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 4bits of subaddress information) when the numbers of
   digits composing subaddress is odd.

      Note: When interworking with SIP it is recommended not to
      translate the padding bits to "isub" parameter.


Appendix B.  Structure of NSAP Addresses




Munakata, et al.        Expires December 10, 2006              [Page 11]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


   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 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 two 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 it
   depends on the value of AFI.

   Typical encoding type of the ISDN subaddress, IA5, is identified as
   AFI=0x50.  When AFI value is 0x50, the length of IDI is zero,
   therefore the length of IDP is 2 digits (1 octet).  In this case, 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 AFI's value set to either 0x50
   or 0x48 is shown below.  As shown, DSP starts from the 2nd octet of
   the NSAP address.










Munakata, et al.        Expires December 10, 2006              [Page 12]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


           +--------------------------------------------------+
           | IDP |                                            |
           |-----|                 D S P                      |
           | AFI |                                            |
           +--------------------------------------------------+
           0     1            ...  Octets  ...          max. 20

        Figure 5  Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)




Appendix C.  Change Log

   Changes from 00 to 01. - Many editorial fixes and grammatical
   correction. - Added a text on "User-Specific" address type. - Added a
   text on "odd/even" indicator. - Changed the requirements to clearly
   address the requirements this draft is trying to meet.

   Changes from 01 to 02. - GEN-ART provided some constructive feedbacks
   and we reflected some of the recommended changes.
   1.  Some of the SHOULD were changed to MUST to hold a better
       compatibility with the pre-existing implementation.
   2.  Fixed numerical grammatical errors.
   3.  Added an appendix to explain the ISDN subaddress information
       element.
   4.  Expanded the appendix on NSAP address structure to clarify some
       of the ambiguity that was addressed.
   5.  Clarified some of the text on entity behaviors.(Section 6)

   Changes from 02 to 03. - Reflected comments provided by IESG.
   1.  parameter defined in this draft was renamed from "isub-type" to
       "isub-encoding".
   2.  Added a reference to a draft handling the IANA registration.


10.  References

10.1.  Normative Reference

   [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.



Munakata, et al.        Expires December 10, 2006              [Page 13]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


10.2.  Informative Reference

   [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 Telecommunications 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.

   [7]  INTERNATIONAL Telecommunications 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 Number
        Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
        Registry",  draft-ietf-iptel-tel-reg-02.txt, May 2006.






























Munakata, et al.        Expires December 10, 2006              [Page 14]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


Authors' Addresses

   Mayumi Munakata
   NTT Corporation

   Phone: +81 422 36 7565
   Email: munakata.mayumi at lab.ntt.co.jp


   Shida Schubert
   NTT Corporation

   Phone: +1 604 762 5606
   Email: shida at 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 at lab.ntt.co.jp
   URI:   http://www.ntt.co.jp


























Munakata, et al.        Expires December 10, 2006              [Page 15]

Internet-Draft  ISDN subaddress encoding type for tel URI       Jun 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Munakata, et al.        Expires December 10, 2006              [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/