|
This draft proposes a modification to draft-lawrence-dispatch-sipforum-provider-alias (PAN). The PAN draft proposes a mechanism for a phone to take a short numeric identifier that identifies a phone service provider and look it up in DNS to find the address of the configuration server for that service provider.
The problem with PAN is that it requires a specific organization, sipforum.org, to become a registrar for the PAN. This will add signifiant cost to obtaining them as the expected quantity of PAN is low. This draft proposes a minor modification to the PAN draft. Instead of using the sipforum as a new registrar, why not just use the registrars that already exist for DNS names. This ensure a long term stable unique allocation of PAN with the advantages of not having the IETF allocating a monopoly to one particular organization.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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.”
This Internet-Draft will expire on January 5, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Currently section 3.1 of the PAN draft proposes to construct a domain name from PAN by taking the PAN and prepending it to the string ".pan.sipforum.org". So a PAN of 555 would result in a NAPTR lookup of the "555.pan.sipforum.org". In the following sections, some alternative proposal are made.
The domain is formed by prepending "pan" and appending ".org" to the PAN so the PAN of 555 would result in a domain of "pan555.org". Organization get a PAN by just getting the domain name in the normal manner.
The domain is formed by prepending "pan" and appending a TLD based on the first digit of PAN where if the first digit is 1, then " .com" is used and if the digit is 2, then ".net" and so on. So the PAN of 2555 would result in a domain name of "pan2555.net".
The domain is formed by treating each pair of numeric digits as base 10 encoded version of the upper case character in the domain string. So a domain iii.ca would be converted to upper case III.CA which is ascii characters 73 73 73 46 67 65 so the PAN would be 737373466765.
A small table of of common occurring sequences of characters in domain names is created and used as a dictionary for a simple way to compress any URI into a decimal string.
The above proposal represent a range of complexity and generality. Some will result in larger PAN numbers than others and some result in more or less code. Some can only using a single TLD (Top Level Domain) while others could work with many or all TLDs.
User clearly have no problem with 10 to 15 digit long phone numbers so it's hard to see a 15 digit PAN being a problem for a user to enter. All of these have significant advantages over allocating sipforum.org as the root of the registration. The processes for ensuring uniqueness of normal DNS names are well understood as well as managing changes in ownership, resolution of disputes, and so on. Replicating all this work inside of the a new organization is expensive. Some casual and likely uninformed estimates have put it in the range multiple hundreds of thousands of dollars to run over a a few year time scale. There is unlikely to be more than 1000 domains using PANs if they are expensive.
It would be nice to have a single digit checksum on the PAN. This can significantly improve the user experience when an entry error is made.
Making a minimum allowable length for PAN will help reduce land grabs of very short PANs.
A generalized numeric encoding for URI will likely have widespread uses as devices with very limited user interfaces become more common. For example, some digital clocks today make the user set the time using a single button. It's not fun but it's possible. Devices like the Apple iTV have a nice user interface for entering a multi digit number using a remote with just 6 buttons.
| Cullen Jennings | |
| Cisco | |
| 170 West Tasman Drive | |
| San Jose, CA 95134 | |
| USA | |
| Phone: | +1 408 421-9990 |
| Email: | fluffy@cisco.com |