It has a section 0 which lists the changes that I planned. In addition, here is a summary of all of the other feedback that I've received to date (except the comments I was able to counter immediately): - The terms global and local seem to be a bit hard to understand. Some global corporations are using local phone numbers globally, and do not seem to understand that these numbers are not "global" even if they are able to use the same PBX numbers in San Jose and London. I guess that this should be elaborated on. - Private-prefix should start with either vnd. (vendor trees) or x- (experimental prefixes). This would simplify the horrible BNF that currently specifies the private-prefix's first character. - For number portability work, future-extensions should contain a non-criticality indicator. This would affect the naming of future extensions as follows: if someone specifies a future-extension, all URL handers must recognise and be able to parse it or reject the URL completely, unless the name of the future extension ends in "-nc" which indicates that the extension is non-critical and can be ignored. I discussed this a lot with James Yu. And the following: > > According to RFC2806 local phone number and other parts of > > the url can > > contain the dtmf-digit '#'. But this character is disallowed in URI > > according to RFC2396 as it is used to delimit a URI from a fragment > > identifier in URI references. Must it be escaped? and: > We recently had a long discussion on the Sip Mailing list and > concluded (among other things :) )that quoted strings should > not be a part of the Sip-URL as it contravines the URI syntax > outlined in RFC 2396 (See section 2.4.3 of RFC 2396 > where it declares the <"> character as excluded). Use of # - RFC2396 (2.4.3), excluded character. We do not use them currently in tel URLs, but we DO have VoIP products that use them and could need them in tel URLs in the future. I have not been personally involved with them but as I understand it, in some regions (e.g., Japan) they are used to address multiple devices on a single BRI line in a home or office. In such an environment, they would be needed to allow addressing only the desired device (e.g., voice phone and avoid getting fax machine). Our VoIP products can currently be configured to accept PSTN calls only if the correct subaddress is set, but do not currently place IP calls specifying a subaddress but may want to in the future. Why do we want to remove the feature? Terry L Anderson DMTS Lucent / Integrated Network Solutions VoIP Access Networks I have a number of concerns with draft-allocchio-gstn-04.txt. In short: - The digit string doesn't include all Hex Digits (notably E, F). From the excellent number portability document that's just going through, these ARE used. - The draft does include network access digits, ?passwords?, pause and "wait for tone"/"wait for off-hook", and post-dial digits - The draft suggests that a GSTN address will be a subset of the definitions it contains. - The draft states that its definitions MUST be used for all documents using dial strings. - The BNF needs work - intermediates are not defined in higher level terms, and there's no explicit separation between parts of the string. Lawrence Conroy: The allocchio draft focuses on "what's on the keypad" rather than what's sent in the network protocols. There are two ways of looking at terminal to network interactions; the "stimulus" and "functional" views. This draft focuses on the "stimulus" view, i.e. what stimuli are applied to the terminal. SIP (and H.323) and pretty much most PSTN network-network signalling uses the "functional" view, i.e. what is intended to happen. There *is* a stimulus protocol definition for ISDN, but the "normal" Q.931 is a functional protocol. Now to the nub...Claudio's draft, with its focus on the terminal, has just the problems that all such drafts have. They are not really usable remotely - a pretty major flaw, from the IETF perspective. For example, the access digits are included in the local phone definition. This is only going to work if the recipient is in exactly the same context as the sender, or one with the same behaviour to these stimuli. If I put "0" as the long distance access digit, this is not going to work in Finland (or Israel). Similarly, for use behind PBXs, what is the "public network access digit"? Is this "9", or "8", or "0"? I know what it is here ("9"), but if I send this to you, I have no way to tell whether this is correct where your terminal dials. Now for the 'actions', "pause" and "wait for tone". There are different timing requirements for access to telephone networks in different places. (Initially, modems in the U.K. had problems with homulgation if they included 'p' and 'w', as these could be programmed for, say, a 10 second wait). Most networks have different inter-digit time-outs for dialling. This means that it is possible to embed a wait in the middle of a dial string that works on one network but doesn't elsewhere. Including Post-dial digits is tricky as well. It requires cooperation between the network and the terminal so that it's clear when the call has been delivered to the destination, and can cause confusing results. Some private networks do not use DTMF "internally", so that the terminal may have to be programmed (pre-call) so that it is routed via a DTMF translator. That particular one caused me a lot of fun trying to work out why calls to the Oracle help line from a customer site didn't work! In summary, the place at which these dial strings are to be used can be different from the place at which it's generated (we are talking about protocols :). These contexts may differ in subtle ways in their behaviour to these stimuli. It's quite hard to check that the behaviour is the same. That's one reason why rfc2806bis has moved away from dial strings and towards addresses - they stand a chance of working in a defined way, leaving the recipient to deal with the functional aspects of how it uses the GSTN. Now for why I'm interested... The draft seems to imply that GSTN addresses are a subset of the definitions it makes. This is (mostly) true, but not always, and can be confusing - I think I know the difference, but maybe some readers won't. At least, it needs a much stronger definition of the scope of use for these dial strings, and not to just say that these things are sub-sets. Also, it states that all documents using dial strings MUST use these definitions. Well....that will cause confusion, IMHO, as 2806bis cannot, as they stand. It means that we need a definition of dial string as opposed to address in every document - Henning has put some text into 2806bis, but there needs to be a narrow definition and applicability statement in the allocchio draft. Finally, the BNF is somewhat strange. A couple of the intermediate terms don't appear in the "higher level" terms. Also, there is no explicit separator between the various parts of the dial string. How do I know whether some digits are "post dial" or part of the main address, or part of the "pre-dial" network access digits? This seems to reflect the * risky* assumption that the recipient will obey the dial sequence * exactly as written, complete with pauses and wait-for-tone commands. I think that Claudio's draft needs a LOT of work in refining the text, the scope and applicability, the semantics behind the syntax, the difference between what is dialled and what is sent through the network, the BNF, and the use of '*' and '#' as opposed to 'B', 'C', 'D', 'E', and 'F'. As a postscript, '*69' doesn't work here, so although dial strings might be considered for service codes, there's a problem there as well; I am not sure that it's theoretically possible to define a stimulus protocol that is applicable outside the context in which it's defined. --- Suggestions: hint to resolution tel URI resolution long-term constant outside of call signaling, e.g., on a web page, in an XML document, in a database, directory or an address book call signaling, e.g., in SIP and H.323 call setup requests 1. use e.g on Webpage: TH, NP, CP should not be used or are not applicable, TD may be useful 2. use in signalling (e.g. INVITE): TH, TD, NP, CP may be useful 3. use in ENUM: TH and CP are not applicable, TD may be usefull, NP is essential (see below) (TH) translation history hints ("translation X has been performed"); (TD) translation directive ("translation X should/should not be performed"); (NP) number property: "the number in the tel URI is a 'foo'" (and it will be a 'foo' for a long time). (CP) call property: the call with this tel URI has the following properties