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:fax=1234@fax.xerox.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.

Received on Monday, 29 June 1998 10:51:11 UTC