martes, 20 de julio de 2010

¿Han pasado ya 10 años desde la idea de los dominio .tel?



                     Internet-Telephony Directory           April 2000     Telephone Number Mapping (enum)                             D. Peek                                                              R. Walter                                                             D. Ranalli    Internet Draft                                              VMA-TWG    Document: draft-peek-enum-itd-00.txt>                    April 2000    Category: Informational                        Internet-Telephony Directory for                     Mapping E.164 to Internet Addresses   Status of this Memo     This document is an Internet-Draft and is in full conformance with    all provisions of Section 10 of RFC2026 [1].     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.  1. Abstract     A holistic directory system is described which translates a standard    E.164 telephone number into the Internet address information    required to support IP-enabled communications applications such as    real-time voice, voice-messaging, fax or unified-messaging. The    proposed system utilizes two logical control tiers to implement the    translation.     The first logical control tier is patterned after a Top Level Domain    (TLD) of the Internet Domain Name System (DNS).  This first-tier    provides a mechanism for locating the appropriate directory within    the second logical tier of the Internet-Telephony directory system    where authoritative Internet address information is stored for a    given E.164 number.  This first-tier is expected to conform to the    regulatory and operational standards defined by the Internet    Corporation for the Assignment of Names and Numbers (ICANN) for the    operation of top-level domains.     The second logical control tier provides a mechanism for accessing    and managing authoritative Internet address information associated    with an E.164 number.  This tier consists of widely distributed DNS    servers controlled by service providers, and corporate network    operators.  Distributed ownership of the second tier directories    allows organizations to control the Internet address information    associated with the E.164 numbers under their day-to-day control.        Peek, Walter, Ranalli     Expires - October 2000                     1 
                     Internet-Telephony Directory           April 2000                             Table of Contents      1.    Abstract                                               1     2.    Conventions used in this document                      3    2.1     Terminology                                          3     3.    Introduction                                           5    3.1     Overview                                             5    3.2     Requirements                                         5     4.    System Description                                     6    4.1     Directory Locator Service (DLS)                      6    4.1.1   The E.164 Domain Name Space                          7    4.1.2   Multiple Application Support                         7    4.1.3   Application Specific E.164 Domain Name Resolution    8    4.2     Authoritative Directory Service (ADS)                9    4.2.1   Resource Record for URI's                            9     5.    E.164 Domain Name Registration                         10    5.1     Background & Scope                                   10    5.2     List Of Actors                                       10    5.3     DLS Registration Process                             11     6.    Application Scenarios                                  11    6.1     SIP appliction                                       11    6.2     VPIM application using LDAP                          12    6.3     VPIM application without LDAP                        12    6.4     Multiple Internet-Telephony service providers        13     7.    Security Considerations                                13    7.1     DLS Security                                         13    7.2     ADS Security                                         13     8.    Prevous Work                                           13     9.    References                                             14     10.   Acknowledgments                                        15     11.   Author's Addresses                                     15     Appendix A.    Conflict Resolution Process                   16     Full Copyright Statement                                     17                Peek, Walter, Ranalli     Expires - October 2000                     2 
                     Internet-Telephony Directory           April 2000  2. Conventions used in this document     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 [2].  2.1 Terminology     A-record             - Address Record; a standard DNS resource                            record.     ADS                  - Authoritative Directory Service. The second                            logical control tier of the Internet-                            Telephony Directory.     DLS                  - Directory Locator Service.  The first logical                            control tier of the Internet-Telephony                            Directory.     DNS                  - Domain Name System     E.164 Number         - International telephone number as defined                            by the ITU E.164/I.331 [13] standard.                            (e.g. 16033624315)     E.164 Subscriber     - Corporation or individual that has subscribed                            to a PSTN service and been assigned one or                            more associated E.164 numbers.     EMA                  - E-Business Forum (www.ema.org)     ENUM                 - IETF Telephone Number Mapping work group.     ITD                  - Internet-Telephony Directory defined in this                            Document.     ITU                  - International Telecommunications Union.  See                            www.itu.org.     ICANN                - Internet Corporation for the Assignment of                            Names and Numbers (ICANN).     IETF                 - Internet Engineering Task Force(www.ietf.org)     Internet Address     - General term that provides a simple and                            extensible means for identifying an Internet                            resource. Used synonymously with a URI.     LDAP                 - Lightweight Directory Access Protocol;     NAPTR-Record         - Naming Authority PoinTeR; a standard DNS                            resource record.     NS-record            - Name Server record; a standard DNS resource                            record      PSTN Carrier         - Telephone company that assigns E.164 numbers                            to E.164 subscribers. (Corporations or                            individuals)   Peek, Walter, Ranalli     Expires - October 2000                     3 
                     Internet-Telephony Directory           April 2000      Registrant           - E.164 subscriber (corporation or individual)                            that has registered one or more E.164                            numbers in the Internet-Telephony directory.     SIP                  _ Session Initiation Protocol; used in                            establishing a voice over IP call.     TXT-Record           - Text record; a standard DNS resource record.     URI                  - Uniform Resource Identifier                            (i.e. sip:joe@acme.com, ldap://server.com)     VMA                  - International Association for Enhanced Voice                            Services. (www.ivma.ch)     VPIM                 - Voice Profile for Internet Mail     Zone                 - A region of a domain name space that is                            managed by a DNS name server.                                           Peek, Walter, Ranalli     Expires - October 2000                     4 
                     Internet-Telephony Directory           April 2000   3. Introduction  3.1 Overview     This document defines the architecture of an Internet telephony    directory system suitable for global deployment.  It draws upon    information contained in the many previous proposals related to    Internet directory services.  This document attempts to extract the    most useful features of each proposal and meld them into an approach    designed to best meet the needs of the entire Internet-Telephony    industry.     A serious impediment to the development and acceptance of Internet-    Telephony services is the different addressing schemes employed by    the Public Switched Telephone Network (PSTN) and the Internet.  A    global directory service that enables the translation of a PSTN    telephone number (E.164 number) into a corresponding Internet    address eliminates this impediment.  The precise nature and    structure of such a directory has been the object of considerable    speculation, research and discussion.  A number of companies and    technical groups, including the VMA, EMA, IETF and various    organizations within the ITU have made numerous contributions to    this effort.     Telephone numbers follow a well-defined format governed by the E.164    standard of the International Telecommunications Union (ITU).    Therefore, translating a telephone number into an Internet address    is a rather straightforward task.  However, complexities emerge as    the concept is expanded globally and extended to include multiple    Internet-Telephony service providers, each providing different    services tied to the same E.164 number.     Consensus appears to have emerged on at least two key points:       -  The Internet Domain Name System (DNS) is an excellent         technology for the first-tier of the Internet Telephony         Directory.       -  A single-tier system cannot adequately meet the needs of all         Internet-Telephony applications.  Scalability, operational         complexity and information control issues, all mitigate against         a single tier model.     The system proposed herein utilizes the Internet Domain Name System    within a two-tier logical control model to translate an E.164    telephone number into an application specific Internet Address.      Please send comments on this document to the ENUM working group or    directly to peek@evds.com.            Peek, Walter, Ranalli     Expires - October 2000                     5 
                     Internet-Telephony Directory           April 2000     3.2 Requirements     The directory solution:          1. MUST be globally accessible.          2. MUST be highly scalable, responsive, and efficient in its            use of network resources.          3. MUST be flexible enough to support the addressing            requirements of all Internet-Telephony applications. (e.g.            Voice messaging, IP-Telephony, Fax, etc.)          4. Must support multiple Internet-Telephony applications per            E.164 number that may be provided by different application            service providers. (e.g. IP-Centrex from one provider and            Unified-Messaging from another application service provider)   4.  System Description     The system proposed herein utilizes DNS within a two-tier control    model to translate an E.164 telephone number into an application    specific Internet Address.  The first-tier is a "Directory Locator    Service" (DLS) that maps an E.164 telephone number into the IP    address of a second-tier authoritative directory.  The second-tier    is an "Authoritative Directory Service" (ADS) that translates an    E.164 number into an application specific Internet address.  4.1 Directory Locator Service (DLS)     The DLS provides the high-level function of referring a requesting    Internet-Telephony application to the Authoritative Directory    Service (ADS) containing the desired Internet address information    associated with an E.164 number.  The DLS is envisioned as a global    resource for the entire Internet-Telephony industry and as such, is    an ideal candidate for an Internet Domain Name System "Top Level    Domain" (TLD).     Following conventions observed with all existing top-level domains,    (i.e., .com, .net, .org, etc.) the DLS utilizes Name Server (NS)    records and associated A records to delegate authority to    subordinate Name Servers.  This system allows an Internet-Telephony    application or platform to iteratively access a hierarchy of DNS    name servers until the desired resource record information is found    or until the search is exhausted.  This process is commonly referred    to as "resolution".  See RFC1034 [12] for more information.     A Directory Locator Service defined as a DNS top-level domain offers    several advantages:          - A top-level Internet domain is a global resource that           operates under a well-defined regulatory and operational           structure.          - Through the use of standard DNS resolution, a single query is           sufficient to locate the desired Internet address           information.     Peek, Walter, Ranalli     Expires - October 2000                     6 
                     Internet-Telephony Directory           April 2000  4.1.1 The E.164 Domain Name Space     The current practice for IETF ENUM working group documents is to use    "e164.foo" when referring to top-level domains.  This document    proposes the creation of a new top-level domain called "tel" as the    root domain of the E.164 domain name space.  Sub-domains of "tel"    may not be arbitrarily defined; rather they are defined in    accordance with the ITU E.164/I.331 [14] standard. For simplicity of    understanding the context and use of this proposed TLD, the examples    in this document utilize the "tel" top-level domain in place of    "e164.foo".     An E.164 standard [14] telephone number consists of a country code    and a nationally specific part.  For reasons of scalability,    reliability and flexibility, the E.164 domain name space should be    partitioned into a number of zones distributed across multiple name    servers.  The segmentation of an E.164 number into a country code    and a nationally specific part, with the latter further segmented by    area-code/city-code, presents natural boundaries for such    partitioning.  4.1.2 Multiple Application Support     One of the key design requirements of the Internet Telephony    Directory is the ability to support multiple Internet-Telephony    applications using a single E.164 number.  For example, a single    E.164 number will frequently be used for both real-time voice    (SIP/H.323) and voice messaging (VPIM) applications.     This multi-application requirement has been addressed in all    previous ENUM drafts.  The Internet-Telephony Directory system    described in this document further advances this concept by enabling    various application specific Internet addresses tied to a single    E.164 number to be controlled by different service providers.     Consider the following scenario:  A company wants to use Service    Provider-A for an IP-enabled real-time voice service and Service    Provider-B for a unified messaging service.  Both service providers    require control over the Internet address information associated    with their respective services.  As a result, the requirement exists    to distribute control of Internet address information at the    application level.  Further qualifying a name within the E.164    domain name space through the addition of an application specific    prefix or "Service Protocol", fulfills this requirement.     The Service Protocol naming conventions associated with various    Internet-Telephony applications are subject to standardization.  For    example, the list of supported Service Protocol names might include:          sip or h323     (for voice over IP applications)         vpim            (for voice messaging service)         smtp            (for e-mail and unified messaging applications)         fax             (for IP-fax applications)     These example names correspond to several of the service names    discussed in the ENUM workgroup.  This list will increase as new and    different IP-communications services become available.      Peek, Walter, Ranalli     Expires - October 2000                     7 
                     Internet-Telephony Directory           April 2000   4.1.3  Application Specific E.164 Domain Name Resolution     Internet-Telephony applications query the DLS using a DNS query    based on an application specific E.164 domain name.  The following    steps define its formulation:     1.   Start with a complete E.164 telephone number.                  Example: +1-603-362-4315     2.   Remove all characters other than digits.                  Example: 16033624315     3.   Reverse the order of the phone number.                  Example: 51342633061     4.   Insert a "." between each digit and at the end.                  Example: 5.1.3.4.2.6.3.3.0.6.1.     5.   Append, as a suffix, the E.164 top-level domain.                  Example: 5.1.3.4.2.6.3.3.0.6.1.tel.     6.   Append, as a Prefix, a "Service Protocol" name indicative of         the desired service.                  Example: sip.5.1.3.4.2.6.3.3.0.6.1.tel.     When a client DNS resolver queries the DLS, the DLS returns the NS-    and A-records which define the IP address of the next DNS name    server.  Upon receipt of the NS and A records from the DLS, the    client resolver reissues the query to the newly discovered name    server.     The following illustrates a sample zone file fragment containing NS    and A records:      4.3.2.1.5.9.4.1.6.1.4.4.tel.        IN NS  ns1.UKSP.tel.                                         IN NS  ns2.UKSP.tel.     5.1.3.4.2.6.3.3.0.6.1.tel.          IN NS  ns1.CompanyA.tel.                                         IN NS  ns2.CompanyA.tel.      ns1.UKSP.tel.                       IN A   208.146.45.55     ns2.UKSP.tel.                       IN A   208.146.45.56     ns1.CompanyA.tel.                   IN A   208.155.55.55     ns2.CompanyA.tel.                   IN A   208.155.55.56             Peek, Walter, Ranalli     Expires - October 2000                     8 
                     Internet-Telephony Directory           April 2000   4.2 Authoritative Directory Service (ADS)     The ADS provides authoritative Internet address information in    support of one or more Internet-Telephony applications associated    with a subset of E.164 numbers.  The ADS is a delegated DNS name    server [12] that must be properly registered with the top-tier DLS.    Any E.164 Subscriber (corporation or individual that has been    assigned one or more E.164 numbers) may register, deploy and operate    an ADS or delegate the function to a third-party service provider.     The ADS will return one of the following results based on a query    using an application specific E.164 domain name.          1. An end-point address in the form of a URI. For example:             Query:   sip.5.1.3.4.2.6.3.3.0.6.1.tel            Result:  sip:user@company.com             Query:   smtp.5.1.3.4.2.6.3.3.0.6.1.tel            Result:  mailto:user@company.com          2. A referral to a non-DNS service in the form of a URI.  For            example, voice messaging applications requiring spoken name            will utilize a referral to an LDAP directory:             Query:   vpim.5.1.3.4.2.6.3.3.0.6.1.tel            Result:  ldap://ldap.company.com:389/e164=16033624315,dc=tel          3. The NS-records and associated A-records for a delegated ADS            that contains the URI for the requested application.  This            ADS delegation feature enables control over various            Internet-Telephony applications tied to the same E.164            number to be delegated out to different service providers.          4. A negative response.  Indicates that no Internet address            information exists for the specific application queried.   4.2.1  Resource Record for URI's     Currently, no standard DNS resource record exists which specifically    maps a domain name to a complete URI.  However, existing resource    records such as the TXT or NAPTR records may be utilized to achieve    the desired effect until a new resource record with the specific    intent of mapping a domain name to a complete URI is standardized    and deployed.     The Text (TXT) resource record provides a simple yet effective    mechanism for associating an E.164 domain name to a URI.  The Domain    Implementation and Specification RFC 1035[15] defines TXT records as    follows:          "TXT RRs are used to hold descriptive text.  The semantics of         the text depends on the domain where it is found."      In the context of the E.164 domain name space, the TXT record is    semantically defined as mapping an application specific E.164 domain    name to a URI.  Both NAPTR and TXT records could be used to    implement this solution.  Neither is perfect for the task at hand    but TXT records have the advantage of being simple, efficient, and Peek, Walter, Ranalli     Expires - October 2000                     9 
                     Internet-Telephony Directory           April 2000     widely supported.  The following example zone file fragment    demonstrates the utility of TXT resource records.       $ORIGIN 2.6.3.3.0.6.1.tel.       sip.5.1.3.4   IN TXT  sip:dpeek@ServiceProvider2.com      smtp.5.1.3.4  IN TXT  mailto:dpeek@acme.com      vpim.5.1.3.4  IN TXT  ldap://ldap.acme.com/e164=16033624315,dc=tel   5.  E.164 Domain Name Registration  5.1 Background & Scope     The creation and eventual assignment of E.164 numbers to end-user    corporations and individuals (E.164 Subscribers) is a well-defined    process that exists within the PSTN today.  The registration of    E.164 numbers in the Internet-Telephony Directory is complimentary    to this existing process and takes place only after a number has    already been assigned by a PSTN Carrier to an E.164 Subscriber.  5.2 List Of Actors     Following the current practice with all Internet top-level domains,    the registration of E.164 numbers in the DLS will be managed by a    single trusted "Registry".  It is assumed that this exclusive    Registry function will fall under the regulatory control of ICANN.    The actors involved in the registration process are as follows:     ICANN:      -  Internet Corporation for the Assignment of Names and Numbers.      -  Selects and regulates the exclusive DLS Registry.      -  Defines pricing for the top-tier regulated DLS service.     DLS Registry:      -  Entity that deploys and operates the globally distributed DLS         service under contract from ICANN.      -  Entity that builds, deploys and maintains a DLS registration         service for use by all E.164 Registrants.      -  Entity that manages the DLS "Conflict Resolution Process".         (See Appendix A for Conflict Resolution Process proposal)     E.164 Registrant:      -  E.164 Subscriber or designated representative that registers         numbers and an associated ADS in the top-level DLS.      -  Entity that either operates its own ADS or outsources the         function to a third-party provider.  (Corporations may choose         to operate their own ADS while individuals are likely to         outsource the function to a service provider)      -  Entity that agrees to the terms and conditions of the DLS         Registration Agreement as set out by the DLS Registry.            Peek, Walter, Ranalli     Expires - October 2000                    10 
                     Internet-Telephony Directory           April 2000   5.3  DLS Registration Process     1. E.164 Registrant deploys an ADS or contracts with a third-party       provider of ADS services.     2. Registrant "registers" one or more E.164 numbers and associated       ADS via the DLS registration service.     3. Registrant agrees to the terms and conditions of the DLS       Registration Agreement as set forth by the Registry under the       control of ICANN.     4. DLS Registration service (operated by the Registry) checks the       Registrants E.164 numbers against the list of existed registered       numbers to determine if a conflict exists.  If no conflict       exists, the registration is approved.  If a conflict exists, the       DLS Registry works with the two parties that have both claimed to       be the valid E.164 Subscriber for the same number to resolve the       conflict. (See Appendix A for a more detailed description of the       Conflict Resolution Process)     5. Registrant pays the DLS Registry fees and any associated conflict       resolution fees as set forth under the DLS Registration agreement       defined by ICANN.     6. DLS Registry makes Registrant name, address, and contact       information freely available via an on-line Who-is database.       This is a requirement for any top-level domain and an important       support feature for the conflict resolution process.     6.  Application Scenarios  6.1 SIP Application     A SIP application seeking to establish a SIP session formulates an    application specific E.164 domain name and issues a single query to    the DLS for the associated TXT-record through a standard DNS    resolver.        Query:   sip.5.1.3.4.2.6.3.3.0.6.1.tel.     The DLS responds to this query with the NS- and A-records of the    appropriate ADS.  The DNS resolver, after receiving the NS- and A-    records, automatically reissues the identical query to the new name    server (ADS).     Note that the SIP application is only aware of the first query. The    DNS resolver automatically reissues queries through the standard    iterative resolution process [12] until the TXT-record information    is returned.        Result:  sip:user@company.com     The requesting SIP application now has the Internet-Telephony    address information it requires to establish a voice over IP call    using the SIP protocol based simply on a telephone number.   Peek, Walter, Ranalli     Expires - October 2000                    11 
                     Internet-Telephony Directory           April 2000  6.2 VPIM application using LDAP     A VPIM application seeking to send a voicemail message over the    Internet formulates an application specific E.164 domain name and    issues a single query to the DLS for the associated TXT-record    through a standard DNS resolver.        Query:   vpim.5.1.3.4.2.6.3.3.0.6.1.tel.     The DLS responds to this query with the NS- and A-records of the    appropriate ADS.  The DNS resolver, after receiving the NS- and A-    records, automatically reissues the identical query to the new name    server (ADS).     Note that the VPIM application is only aware of the first query. The    DNS resolver automatically reissues queries through the standard    iterative resolution process [12] until the TXT-record information    is returned.        Result:  ldap://ldap.acme.com:389/e164=16033624315,dc=tel     Using the LDAP URI, the VPIM application queries the LDAP directory    to retrieve a VPIM address and "spoken name" via the standard VPIM    schema [4].  Note, the LDAP directory is used in this scenario to    retrieve an audio representation of the destination party's name    that cannot be easily stored in a DNS directory.     6.3 VPIM application without LDAP     LDAP is clearly the technology of choice to manage and store complex    VPIM user information such as spoken-name, audio encoding types, and    other VPIM related address.  However, the installed base of LDAP    servers is limited at present and their increased operational    complexity may inhibit some organizations from deploying enhanced    VPIM services.  For organizations that are not prepared to operate    an LDAP directory, the ADS can be provisioned to return VPIM mailbox    addresses in the form of a mailto URI.  For example:        Query:   vpim.5.1.3.4.2.6.3.3.0.6.1.tel.        Result:  mailto:610002@sprovider.net     By returning a mailto URI the organization forfeits the ability to    supply spoken-name and other enhanced capabilities to querying VPIM    applications.               Peek, Walter, Ranalli     Expires - October 2000                    12 
                     Internet-Telephony Directory           April 2000   6.4  Multiple Internet-Telephony service providers     A company wants to use Service Provider-1 (SP1) for an IP-enabled    real-time voice service and Service Provider-2 (SP2) for a unified    messaging service.  Both service providers require control over the    Internet address information associated with their respective    services.  As a result, the requirement exists to distribute control    of Internet address information at the application level.     To achieve this objective the Company utilizes the inherent    delegation capabilities of the ADS and provisions its application    specific E.164 domain names to reference the appropriate service    provider:     sip.0.0.0.5.2.6.3.3.0.6.1.tel      IN NS ns.SP1.tel    vpim.2.0.0.5.2.6.3.3.0.6.1.tel     IN NS ns.SP2.tel                        ns.SP1.tel     IN A  208.150.79.113                        ns.SP2.tel     IN A  78.21.79.114   7. Security Considerations  7.1 DLS Security     All data stored in the DLS is considered public Internet-Telephony    information and may be retrieved by any requesting Internet-    Telephony application.  7.2 ADS Security     All data stored in the ADS is considered public Internet-Telephony    information that may be retrieved by any requesting Internet-    Telephony application.    8. Previous Work     Many of the concepts outlined in this document are drawn from two    years of direct experience associated with implementing a directory    service in support of the voice messaging industry initiative called    the "Global Voice Mail Service" or GVMS.     The International Association for Enhanced Voice Service (formerly    the Voice Mail Association or VMA) created and began funding the    GVMS initiative in early 1997.  The goal of the GVMS initiative has    been to connect service provider and enterprise voicemail platforms    on a worldwide basis via the Internet.  Key functionality    demonstrated through the GVMS initiative included the ability for    end-users to send voice messages or reply to voice messages over the    Internet without incurring the long distance charges associated with    placing a return telephone call.     Eight leading voicemail vendors participated in creating the GVMS    solution that was demonstrated at VMA conferences in Athens (98),    Helsinki (99) and at Telecom 99 in Geneva.  The vendors include    Comverse, Brite, Glenayre, Lucent, Nortel, Tecnomen, Alcatel, and    UNISYS.  NetNumber.com, Inc. (formerly EVDS) provided the global    directory service supporting the GVMS demonstrations.   Peek, Walter, Ranalli     Expires - October 2000                    13 
                     Internet-Telephony Directory           April 2000  9. References     [1] Bradner, S., "The Internet Standards Process -- Revision 3",         BCP 9, RFC 2026, October 1996.     [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement         Levels", BCP 14,RFC 2119, March 1997     [3] Faltstrom, P., "E.164 and DNS", Work in progress,         <draft-faltstrom-e164-05.txt>,January 2000     [4] Brown, A., "E.164 Resolution", Work in progress,         <draft-brown-e164-01.txt>, October 1999     [5] Brown, A., "Enum Requirements", Work in progress,         <draft-ietf-enum-00.txt>, NOvember 1999     [6] Vaudreuil, G., "Voice Messaging Directory; Address Resolution         Services", Work in progress, <draft-vaudreuil-ars-01.txt>,         December 1999     [7] Vaudreuil, G., "Address Validation Service", Work in progress,         <draft-vaudreuil-avs-00.txt>, December 1999     [8] Vaudreuil, G., "Telephone Number Base Directory Service", Work         in progress, <draft-vaudreuil-e164dir-00.txt>, March 2000     [9] Shockey, R., "The Use of DNS based E.164 Resolution Services by         Internet Fax", Work in progress,         <draft-shockey-e164toifax-00.txt>, December 1999     [10] Berners-Lee, T., "Uniform Resource Identifiers (URI): Generic         Syntax", Standards Track,  RFC 2396, August 1998     [11] Daniel, R., Mealing, M, "Resolution of Uniform Resource         Identifiers using the Domain Name System", Experimental,         RFC 2168, June 1997     [12] Mockapetris, P., "Domain Names - Concepts and Facilities",         STD 13, RFC 1034, November 1987.     [13] ITU-T Rec, "The International Public Telecommunication         Numbering Plan", Recommendation, ITU-T Rec. E.164/I.331 ,         May 1997.                   Peek, Walter, Ranalli     Expires - October 2000                    14 
                     Internet-Telephony Directory           April 2000   10. Acknowledgments     Our special thanks to Dr. Thomas P. Sosnowski for his help in    editing this document. Also thanks to Chuck Santos for providing us    with many technical details.  We would also like to recognize Anne    Brown, Greg Vandreuil, and Patrik Falstrom for their previous work    in this area.  Thanks also to Michael Mealling for providing us with    details on NAPTR records.   11. Author's Addresses     David P. Peek      VMA, Technical Working Group Chairman      13 Village Drive      Atkinson, NH  03811      Phone: 1-603-362-4315      Email: peek@evds.com     Robert Walter      NetNumber.com, VP Development & Operations      Wannilancit Technology Center      650 Suffolk Street, Suite 307      Lowell, MA 01854      rwalter@netnumber.com     Douglas Ranalli      NetNumber.com, President/CEO      Wannilancit Technology Center      650 Suffolk Street, Suite 307      Lowell, MA  01854      dranalli@netnumber.com                              Peek, Walter, Ranalli     Expires - October 2000                    15 
                     Internet-Telephony Directory           April 2000   Appendix A:  Conflict Resolution Process:     Conflict over the registration of numbers in the top-level DLS could    occur for one of three general reasons:       -  Data Entry Error:  E.164 Registrant makes a data entry error         during the DLS registration process and inadvertently registers         a wrong number.       -  Old Data Error:  E.164 Registrant returns day-to-day control         over one or more numbers to the originating PSTN carrier but         fails to update the DLS registration records.  Example:  A         corporation shuts down an office, terminates its phone service         but fails to un-register the numbers in the DLS.       -  Intentional Error:  E.164 Registrant intentionally claims to be         the E.164 Subscriber that has day to day control over a number         when in fact they are not.     Conflict occurs when two Registrants both claim to be the valid    E.164 Subscriber for the same number.  Conflict over ownership of a    name or number in the Internet naming space is not a new problem.    In the domain name space conflict occurs when one entity registers a    name like "McDonalds" in a top-level-domain (mcdonalds.com) and then    another entity claims trademark control over the name "McDonalds".    In the case of the E.164 domain name space, conflict can be easily    resolved because it is clear how the day-to-day control of a number    is defined:       -  PSTN Service Provider Control:  A PSTN Service Provider         (telephone company) that has registered an E.164 number in the         Internet-Telephony directory on behalf of a customer can         certainly validate the identity of the E.164 Subscriber.       -  E.164 Subscriber Control:  A corporation or individual that has         been assigned a number through the normal PSTN provisioning         process is the E.164 Subscriber and is the only valid         Registrant for that number.  Confirmation of such assignment         can be obtained through reviewing PSTN billing records.     Conflict is identified when an entity attempts to register a number    that has already been registered by another E.164 Registrant.  The    burden of maintaining a system for resolving conflict in an orderly    process falls on the DLS Registry.  A process might operate under    the following principles:       -  Cost of resolution should be born by the mistaken party:  It         seems reasonable to expect E.164 Registrants to take         responsibility for their own mistakes.  If the DLS Registry is         required to take action to correct a registration mistake made         by a Registrant then the mistaken party should pay the direct         costs associated with the resolution process.  The terms of         such a process can be outlined in the DLS Registration         Agreement signed by each E.164 Registrant.        Peek, Walter, Ranalli     Expires - October 2000                    16 
                     Internet-Telephony Directory           April 2000        -  Cost of conflict resolution should be zero:  In most cases,         conflict will be the result of a simple human error.         Registrants that make a data entry mistake should be given an         opportunity to correct the mistake at zero cost.  An on-line         system can easily be maintained by the DLS Registry to identify         conflicts, notify the appropriate Registrant, and enable on-         line corrections.  In the event that the entire process can be         managed via an automated on-line process and resolved in a         reasonable period of time then the cost to all parties should         be zero.       -  Billing records can be used to clarify difficult conflicts:  In         the most difficult case where two entities claim control over a         number and the conflict cannot be resolved through an automated         system, billing records can be used to clarify day to day         control over a number.  Extended conflict like this is likely         to be rare, particularly in light of the provision that the         mistaken party is required to pay the direct cost of conflict         resolution under this model.    Full Copyright Statement     "Copyright (C) The Internet Society (date). 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.         Peek, Walter, Ranalli     Expires - October 2000                    17 
comparador seguros  comparador seguros aeropuerto hoteles aeropuerto hoteles prestamos teléfonos portátiles móviles joyería 

No hay comentarios:

Publicar un comentario