W3C home > Mailing lists > Public > uri@w3.org > October 1999

RESEND: Last Call: URLs for Telephone Calls to Proposed Standard

From: Larry Masinter <masinter@parc.xerox.com>
Date: Sat, 16 Oct 1999 14:01:43 PDT
To: <uri@w3.org>
Message-ID: <000001bf1819$a6f9c8e0$15d0000d@copper.parc.xerox.com>
(was also to: <iesg@ietf.org>, <antti.vaha-sipila@nokia.com>)

Comments on draft-antti-telephony-url-11.txt:

The first two paragraphs of section 1.1 should either be
edited into a 'history' appendix or else just removed
from the final document.

"Formal definitions follow [RFC2234]."
 But only the ABNF used in formal definitions follow 2234.

"Requirements are indicated by capitalized words as
specified in [RFC2119]."

but RFC 2119 says:

    Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

since, of course, other words are capitalized.

   In this document, "user agent" means software that can detect and
   parse one or more of these URLs and possibly place a call to the
   remote terminal using hardware and software at its disposal after it
   has been properly configured, or otherwise utilize the contents of
   the URL.

but many pieces of software use URLs that are not "user agents".
The term "user agent" has a well-established usage which doesn't
correspond to this definition.

   None of the URL schemes do have a 'path' in them - they are always

There are (unfortunately) a number of different documents that
attempt to define "URL". This document seems to reference RFC 1738;
however, the BNF and terminology for URLs and URIs were revised
in the transition to Draft Standard RFC 2396; I think that it
would be best to do a careful review of terminology.

For example, RFC 2396 notes that the "path" is applicable whether
or not a URL has a hierarchical component. I think what the author
intends to say here is something like:

  The "tel", "fax" and "modem" URL schemes defined here do not
  use the hierarchical URL syntax; there are no applicable
  relative URL forms.

I don't understand the value of using encoded characters in the

      private-prefix        = (%x21-22 / %x24-29 / %x2C-2F / %x3A /  %x3C-40 /
                              %x45-60 / %x65-7E) *(%x21-3A / %x3C-7E)
                              ; Unsafe and reserved characters must be encoded
                              ; as explained in [RFC1738]

The description of <private-prefix> doesn't help.
%x21-22 isn't a proper terminal in ABNF, as far as I can tell.
Is this intended to mean "%x21" / "%x22", or the actual 
characters themselves with some note about re-encoding them
when necessary?

      token-char and quoted-string

are both used in 'future extension', but the definition of 
'future extension' and its use is very unsatisfying. I don't
understand the extensibility mechanism. An extensibility mechanism
with a rule:

   Implementations MUST be prepared to handle additional and/or unknown
   parameters gracefully. Implementations MAY opt not to use the URL if
   it contains unknown parameters.

is no extensibility mechanism at all; if you use an extension,
it may or may not be ignored, it might make the whole thing
illegal. In general, a useful extensibility mechanism needs
to establish rules about when new extensions are ignored or
cause processing failures.

   For example, <future-extension> can be used to store application-
   specific additional data about the phone number, its intended use, or
   any conversions that have been applied to the number.  Whenever a
   <future-extension> is used in an open environment, its syntax and
   usage MUST be properly documented in an RFC.

In a non-"open environment", users can do what they want, and
define tel:home to mean "phone home", so the precondition just
means that all future extensions require revising or updating
this RFC. If that's the case, why not just leave it out?

I am unhappy with the use of local dial strings and
implementation-dependent parameters in these URLs. I know that
they have use in many pieces of software, just as "file:" URLs
might, and I know that we allowed local dial strings in RFC 2303.
But I think a stronger case should be made for allowing local
information to escape. In RFC 2303, there was always the explicit
context of the RHS of the email address. But "phone-context"
here isn't nearly well-enough defined or itself globally
unique to provide enough context to disambiguate local dial strings
when sent from one system to another.

Since this memo doesn't claim to document existing practice but
rather construct a new telephone number naming scheme, it would
seem reasonable to push harder on global semantic consistency;
if you must supply a "local dial string" then also supply the
identity of at least some domain for which the dial string is local.

Maybe that would warrent using the hierarchical form, e.g.,


means "dial 4333 from a phone which has the same
local dial context as 'telswitch.parc.xerox.com'".

   This kind of
   phone number MUST NOT be used in an environment where all users of
   this URL might not be able to successfully dial out by using this
   number directly.  However, this might be appropriate for pages in a
   company intranet.

We constantly have problems with users putting non FQDNs in
internal URLs. http://parcweb/blah instead
of http://parcweb.parc.xerox.com/blah and then having non-local
users not be able to reach the pages for no good reason.

With telephone calls, the problem is even worse! Someone in HR
will put up a web page "Call tel:1234 for important benefits information",
the page will be mentioned in some inter-divisional memo, and
suddenly everyone in New York is dialing THEIR '1234' local
dial string, and the person at New York's 1234 gets spammed with
phone calls.

This is dangerous, and, using the local dial string syntax suggested
here, unavoidable.

Don't do it.


Received on Saturday, 16 October 1999 17:01:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:01 UTC