Cisco

170 West Tasman Drive San Jose CA 95134 USA +1 408 421-9990 fluffy@cisco.com

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

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.