Message-Id: <355C4C5517A5D111A25800805FEA72A115C491@nmpies02tr.nmp.nokia.com> From: "Vaha-Sipila Antti (NMP)" <firstname.lastname@example.org> To: "'EXT Larry Masinter'" <email@example.com> Cc: URI distribution list <uri@Bunyip.Com>, Date: Fri, 26 Jun 1998 14:17:27 +0200 Subject: RE: telephone URLs, comments on draft-antti-telephony-url-04 Hello, (I am not sure whether this mail gets to URI mailing list since this address has not subscribed it - if it doesn't, could someone please forward it there? Thanks.) You asked some valid questions, some of which have been addressed earlier. I tried to dig into my archives of past mail and quote people that have sent me mail, but unfortunately I haven't saved every piece of discussion. L. Masinter: > I suggest removing "local-phone-number". In the case of > the fax specifications, there was always an 'offramp' to which > the phone number was being made local, but in the case of the URL, > there is no context. This is true. Unfortunately, not all phone numbers are accessible using a global numbering scheme. Such a case might be a freephone number which is only accessible from a certain country; numbers under a company PBX; network specific numbers (my mobile phone operator uses a three-number code to access my voice mailbox), etc. The concept of local numbers has been thought to be important by several individuals, and I presume that this is not a minor issue when thinking about telephone operators and their possible value-added services. You mention later that it could be possible to support local phone numbers with "post-dial" sequence, but this is not true since the purpose of "post-dial" is to guide the user agent to send a string of numbers to the telephone line using DTMF or pulse dialing. We cannot presume that all user agents which require local numbering use DTMF or pulse dialing to set up the call. Also, in my opinion, this would only be a way to dodge this problem with an even worse solution. What I would like to see would be some kind of meta-information in the document in which the URL is found. This meta-information, in machine readable (and parseable) form would describe the context in which the URLs would be interpreted. How to include meta-information in web documents in general is fortunately outside the scope of this document. L. Masinter: > A URL is a Uniform Resource Locator, and "uniform" means that a > URL should identify the same resource no matter where it is accessed. Yes, but doesn't the "locator" mean that information about the method of getting to that location should also be present? URNs (uniform resource names) are used it does not matter where the resource is accessed. Or have I mixed up the terminology? L. Masinter: > If there is some context that is missing, then relative URL forms > are used, with the base supplying the rest of the form. [...] > so that you would write > phone://358/55/1234567;postd=pp22 > instead of > phone:+358-55-1234567;postd=pp22 > This is consistent with the URI generic syntax. However, in this case, there might not be a "base" at all, since phone numbers may indeed be dialable only from inside a certain network or a branch exchange. Again, consider the special access number I have for my voice mailbox: whenever I dial XXX from my mobile, I get there, but I cannot do that from another phone, not even from another network than my home network, no matter what I dialled. In other words, phone numbers do not translate well into a hierarchical structure. draft-fielding-uri-syntax-03.txt talks about an "authority component" prefixed by "//", so that "authority component is typically defined by an Internet-based server or a scheme-specific registry of naming authorities". Most normal phone numbers have this structure (their country code and operator/area prefixes are logical components). However, a lot of phone numbers do not have these components, even if they are not "local" numbers (in the sense that emergency numbers are the same in a lot of countries, so they are effectively "local" for half of the world). 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. > I would like to (re)consider whether separate schemes for > 'tel', 'fax' and 'modem' should be used, rather than having > the 'call style' be a parameter, if such is necessary. > The URL uniformly locates the resource, and doesn't need to > specify the service that is to be obtained at that resource. 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). Supposing that the resource is a telecommunications equipment, this is directly analogous: the URL scheme describes which type of call has to be made to get access to the telecommunications equipment. (In some telephone networks, there are really different "types" of calls, so it is not only the choice of hardware which is used by the user agent to call out.) If the URL does not have any information about whether the remote resource is a telephone, a fax machine, or a modem, the URL is almost unusable since it has no practical use. (Autodetection of the B subscriber does not work if the underlying network needs to know the call type when setting up the call.) If there is a "call style" parameter, the resulting URL syntax might become truly horrible, not easily memorizable, and prone to errors. The original proposal (draft-antti-telephony-url-00.txt) tried to do just this, and the general response was that separate URL schemes would be preferable. L. Aronsson put it very nicely (when referring to -00.txt, which had a call-type parameter): > My general reaction to your proposal is that it is too complicated. > If anything, I would like to cut away parts and options that will be > seldom needed, and that only serve to confuse the user. The user that > I envision is a corporate webmaster or a teenager that wants to put > telephone and fax numbers on a web page. Their understanding of > telephone technology is barely enough to write their numbers on a > business card. For an URL scheme to work, the syntax needs to be as > simple as possible. The same issue is addressed in draft-fielding-uri-syntax-03.txt: > A URI often needs to be remembered by people, and it is easier > for people to remember a URI when it consists of meaningful > components. "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. 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. 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. Also, I have been told that there already exist implementations for the "tel" URL scheme, using the "normal" numbering system. 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. 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. Hopefully this answered some of your questions. Best regards, Antti -- firstname.lastname@example.org - Personal: email@example.com Replying to a mailing list? Cc: me. Opinions are mine, not of my employer.