Re: telephone URLs, comments on draft-antti-telephony-url-04

Al Gilman (asgilman@access.digex.net)
Sat, 27 Jun 1998 14:26:42 -0400 (EDT)


From: Al Gilman <asgilman@access.digex.net>
Message-Id: <199806271826.OAA03411@access5.digex.net>
To: fielding@kiwi.ics.uci.edu (Roy T. Fielding)
Date: Sat, 27 Jun 1998 14:26:42 -0400 (EDT)
Cc: antti.vaha-sipila@nmp.nokia.com, uri@Bunyip.Com
In-Reply-To:  <9806270139.aa11280@paris.ics.uci.edu> from "Roy T. Fielding" at "Jun 27, 98 01:39:47 am"
Subject: Re: telephone URLs, comments on draft-antti-telephony-url-04

to follow up on what Roy T. Fielding said:

> There is only one naming authority (partitioned into sub-authorities)
> for the entire telephone namespace.  Therefore, it makes sense to only
> have one URL scheme for phone names.  The action to take (fax, talk,
> etc.) should be independent of the URI.

The fact that POTS and FAX etc. are all amalgamated under one 
indexing scheme (as you have elegantly stated here) is IMHO the
argument that tells the tale, here.
 
> >HTTP and FTP URLs both locate a resource - a file. Implicitly they also
> >specify which kind of connection has to be made to retrieve that file
> >(which protocol to use).
> 
> Sorry, but that is completely wrong.  This is explained in the introduction
> to the URI syntax spec.

On the other hand, we might want to stear clear of this argument.

Even if we do view url schemes as linked to different methods of
connecting with a remote resource, the point in fact as regards
voice vs. FAX is that the methods used are identical.  The phone
nuber is a parameter for the phase of the process which starts
with obtaining a dial tone locally and ends when you have a ring
indication returned from the remote connection.

That is the same for voice and FAX.

The difference between voice and FAX is more like the difference
between an http: URL for a CGI script vs. an http: URL for a
text/plain document.  There is a difference in what you do after
you access the resource, but not in how you access it.  This
should be made clear in link metadata of some sort, but I at
least am fully convinced by your first argument that these should
be known to the URI architecture as one scheme.

Al