From: "Larry Masinter" <firstname.lastname@example.org> To: "Vaha-Sipila Antti (NMP)" <email@example.com> Cc: "URI distribution list" <uri@Bunyip.Com>, <firstname.lastname@example.org>, <email@example.com> Date: Sat, 27 Jun 1998 17:06:41 PDT Message-ID: <firstname.lastname@example.org> In-Reply-To: <355C4C5517A5D111A25800805FEA72A115C491@nmpies02tr.nmp.nokia.com> Subject: RE: telephone URLs, comments on draft-antti-telephony-url-04 If it isn't clear, I withdraw the suggestion to (re)consider unifying the tel/modem/fax schemes, as the rationale is clear. Perhaps it would be useful to include the rationale in the document, namely: some subscriber networks require different call-setup, so the access methods are different, the same phone number accesses different resources if the call is voice, fax, or modem. > This would then imply that support for local phone numbers should be > abandoned altogether, but this would remove much of the applicability > and the dreaded "market potential" from these URLs. phone://us/911 From anywhere in the US, dial 911 phone://local/911 From anywhere, dial 911 phone:///911 From anywhere, dial 911 > "tel" and "fax" are often found in business cards; humans tend to write > down telephhone numbers using that notation. In this respect, this would > be in alignment with the "easy to remember" requirement. Yes, I agree. But people are used to "//" in URLs anyway, too. > Some other things that should have kept in mind: > > IETF-FAX already published an RFC which specifies a format for phone > numbers. This syntax was almost directly copied to > draft-antti-telephony-url, since it was thought that it would be a > *good* thing to have a *single* syntax for phone numbers, whether they > are in mail addresses or URLs. But mail addresses include a RHS which is the context of interpretation for the 'local phone' which doesn't exist for a URL. Consider the mapping: fax://fax.xerox.com/1234 ==> mailto:email@example.com i.e., a 'fax' URL is mapped to 'use Internet-Fax to send mail to the email address'. > E.123, which is an ITU-T recommendation for phone numbers, uses the > "normal" notation. Splitting the phone numbers to a relative URL based > on their components is against the well-known practice of how people > write phone numbers, and since phone numbers have been around a bit > longer than URLs (almost a century?), in my opinion we should definitely > have "legacy support" here. I would support an equivalence, e.g., fax:+1-650-812-4333 == fax://1/650/812-4333 The E.123 notation for telephone numbers isn't a century old, though, and at least in my circles less commonly understood. That is, I've had to explain the "+ country-code city-code number" notation to a number of people who understood what a URL was but weren't familiar with the international numbering plan. > Also, I have been told that there already exist implementations for the > "tel" URL scheme, using the "normal" numbering system. I've heard this rumor, but it would be good to see if we could find these implementors and get them into the discussion. > Phone numbers (in their international form) are unambiguous, and one > would need information on country codes and area prefixes if he would > like to create a hierarchical URL based on an E.123 style phone number. > The creator of the URL will potentially have to know all country codes > and area prefixes inside that country to be successfully able to write > down the URL. I don't understand this. I've gotten a number of business cards from Europe recently, and either the international notation is clear (e.g., the city code is in parens) or else the number is local, and I have to figure out the dial code by looking up the country code. Are you saying that people will hand out their international telephone number without being clear about which part of the telephone number is the country code? Or is it just the division between city/region/area code and the rest of the number? I could easily imagine making phone://41/1234567 dial-equivalent to phone://41/123/4567 e.g., the area/city code is entirely optional. Something like this (sorry if the BNF is a little sloppy): url == [ "phone" | "fax" | "modem" ] ":" number options number == hierarchical-number | global-number hierarchical-number = [ "//" country-code ] [ "/" area-code ] local-number global-number = "+" country-code [punctuation] [area-code [punctuation]] local-number local-number = digit *(digit|punctuation) country-code = +digit area-code = +digit > However, when someone is using a phone number to dial out, > he needs to know the local country and area codes in any case, even if > the URL was hierarchic I didn't understand this. I think you're saying that "hierarchic URLs don't remove the need to know the local country & area code", which I don't contest, but I don't understand the relevance.