Re: New URL schemes

On Tue, 19 Aug 1997, Lars Aronsson wrote:

> Martin J. Dürst schrieb:
> > it's in your own interest to participate in this discussion in
> > a productive manner, so that we can finish quickly.
> 
> So I hope to do.  But I understand that I also need another working
> group for my primary focus.

No, you don't. As far as I understand, there is currently no requirement
that a standards-track document (which you will probably need for getting
the URL accepted) is backed up by a group.


> I am currently sticking my head into the
> PINT group, which is doing some things that are related to telephones.

Every participation with a group doing related things is of course a
good thing.


> I hear rumors of unwritten (?) rules (?) that URLs can only reference
> "Internet resources", or else they cannot be URLs.

In some sense, that's true. The IETF has probably no interest getting
things standardized that have no relation to the internet.


> Is that so, and
> how does one determine whether a particular kind of resources is on
> the Internet?  For "mailto:" URLs, my browser can send mail over UUCP,
> which is not based on TCP/IP.  For "news:" URLs, my browser can start
> the "readnews" program that accesses a cnews disk structure on the
> local host, and does not have to use the NNTP protocol.  So it seems
> hard to uphold a strict requirement on resources being "on the
> Internet".

It's at least the case that these resources can *also* be accessed over
the Internet, or that they originally or ultimately, or in between, may
use the Internet. Also, if I have the Internet mechanisms available,
I can access these resources, and know how. In this sense, the URLs
are self-contained.


> > What is absolutely not clear from your examlpes is e.g. what a
> > browser is supposed to do with a "tel:" or "fax:" URL when it
> > receives one. There are various widely differing possible answers
> 
> Yes and no.  The thing you "do" with a telephone number is you dial
> it, to make a telephone ring on the other side of the globe, and then
> you speak to the person or machine that answers.  There is no
> ambiguity to this part.  How you technically accomplish this is not
> and should not be specified by the URL scheme.  There could be many
> ways, and this opens up to lots of inventions from software, hardware,
> and system designers.  In the most low-tech scenario, a pop-up window
> could show the number in enlarged digits, so the user can more easily
> see it while manually dialing it.  Other scenarios include
> Internet-carried telephone services.

The problem is that some of these scenarios may need additional
mechanisms, such as dictionary lookup,... This in turn may need
additional parameters. As a typical example, assume that I want
to say that you can reach my telephone over internet by contacting
host xxx.yyy.zzz at port 12345 and using protocol ABCD, because
from there on I pay the connection to my number. Now either we
have a service in place that helps you find this out based on the
URL, or we define a way to include these parameters in the URL.
As we don't currently know which way technology will go, it may
indeed be premature to stanardize something as *the* phone URL.

Exactly these and similar problems were discussed in the IETF
Fax WG in Munich last week.


> In the same way as for "mailto:" or "news:" URLs, the user that clicks
> on a telephone or fax URL in a hypertext document would have to have
> his browser software configured to do the right thing, which is the
> right thing for this particular user, using the Internet as a carrier
> or not.

The problem for connecting the Internet and the phone system is that
there is/are no well-established connection models yet. Usual URL
descriptions give at least examples of what a browser (or other software)
will typically do when that URL is activated, in terms of other
protocols.


Regards,	Martin.