rfc2916.txt

<VC++网络游戏建摸与实现>源代码


RFC 2916                  E.164 number and DNS            September 2000


   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR records in
   the zone that is changed. The use of this in an environment where
   IP-addresses are for hire (for example, when using DHCP [11]) must
   therefore be done very carefully.

   There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,
   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

6. Acknowledgements

   Support and ideas have come from people at Ericsson, Bjorn Larsson
   and the group which implemented this scheme in their lab to see that
   it worked.  Input has also come from ITU-T SG2, Working Party 1/2
   (Numbering, Routing, Global Mobility and Service Definition), the
   ENUM working group in the IETF, John Klensin and Leif Sunnegardh.

References

   [1]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
        (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

   [3]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
        1998.

   [6]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
        2000.




Faltstrom                   Standards Track                     [Page 6]

RFC 2916                  E.164 number and DNS            September 2000


   [8]  Howes, T. and M. Smith, "An LDAP URL Format", RFC 1959, June
        1996.

   [9]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [10] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

   [11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

Author's Address

   Patrik Faltstrom
   Cisco Systems Inc
   170 W Tasman Drive SJ-13/2
   San Jose CA 95134
   USA

   EMail: [e-mail]
   URI:   http://www.cisco.com




























Faltstrom                   Standards Track                     [Page 7]

RFC 2916                  E.164 number and DNS            September 2000


Appendix A. Scenario

   Say that the content of the e164.arpa zone is the following:

   $ORIGIN e164.arpa.
   6.4 IN NS ns.regulator-e164.example.se.

   The regulator has in turn given a series of 10000 numbers to the
   telco with the name Telco-A. The regulator because of that has in
   his DNS.

   $ORIGIN 6.4.e164.arpa.
   6.7.9.8 IN NS ns.telco-a.example.se.

   A user named Sven Svensson has from Telco A got the phone number
   [phone]. The user gets the service of running DNS from the
   company Redirection Service.  Sven Svensson has asked Telco A to
   point out Redirection Service as the authoritative source for
   information about the number [phone].  Telco A because of this
   puts in his DNS the following.

   $ORIGIN 6.7.9.8.6.4.e164.arpa.
   4.3.2.1 IN NS ns.redirection-service.example.se.

   Sven Svensson has already plain telephony from Telco A, but also a
   SIP service from the company Sip Service which provides Sven with
   the SIP URI "sip:[e-mail]".  The ISP with the name
   ISP A runs email and webpages for Sven, under the email address
   [e-mail], and URI http://svensson.ispa.se.

   The DNS for the redirection service because of this contains the
   following.

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 10 10 "u" "sip+E2U"    "!^.*$!sip:[e-mail]!"        .
    IN NAPTR 10 10 "u" "mailto+E2U" "!^.*$!mailto:[e-mail]!"     .
    IN NAPTR 10 10 "u" "http+E2U"   "!^.*$!http://svensson.ispa.se!" .
    IN NAPTR 10 10 "u" "tel+E2U"    "!^.*$!tel:[phone]!"       .













Faltstrom                   Standards Track                     [Page 8]

RFC 2916                  E.164 number and DNS            September 2000


   A user, John Smith, want to contact Sven Svensson, he to start with
   only has the E.164 number of Sven, i.e. [phone].  He takes the
   number, and enters the number in his communication client, which
   happen to know how to handle the SIP protocol.  The client removes
   the dashes, and ends up with the E.164 number [phone].  That is
   what is used in the algorithm for NAPTR records, which is as
   follows.

   The client converts the E.164 number into the domain name
   4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for
   this domainname.  Using DNS mechanisms which includes following the
   NS record referrals, the following records are returned:

   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
    IN NAPTR 10 10 "u" "sip+E2U"    "!^.*$!sip:[e-mail]"        .
    IN NAPTR 10 10 "u" "mailto+E2U" "!^.*$!mailto:[e-mail]"     .
    IN NAPTR 10 10 "u" "http+E2U"   "!^.*$!http://svensson.ispa.se" .
    IN NAPTR 10 10 "u" "tel+E2U"    "!^.*$!tel:[phone]"       .

   Because the client knows sip, the first record above is selected,
   and the regular expression "!^.*$!sip:[e-mail]" is applied to
   the original string, "[phone]". The output is "sip:[e-mail]"
   which is used according to SIP resolution.




























Faltstrom                   Standards Track                     [Page 9]

RFC 2916                  E.164 number and DNS            September 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Faltstrom                   Standards Track                    [Page 10]