Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses
Note: This ballot was opened for revision 05 and is now closed.
(Thomas Narten) Discuss
But a rather weak DISCUSS at that. abstract does not pass ID nits Also do we really need to use MUST in abstracts? I would think not. This memo describes the full text string representation method. This specification was explicitly created to provide an easy, unique and complete reference which MUST be used by all other specification needing a text string representation for a Dial Sequence. Doesn't seem appropriate to say everyone else MUST use this spec. SHOULD would be sufficient. I could also be pedantic, and question whether 2119 terminology is even appropriate when making such general requirements on future specifications. We get into somewhat iffy territory when we say future specs MUST do X.
(Ned Freed) Yes
(Harald Alvestrand) No Objection
(Steven Bellovin) No Objection
(Randy Bush) No Objection
(Bill Fenner) No Objection
(Allison Mankin) No Objection
(Erik Nordmark) No Objection
(Jon Peterson) No Objection
I would have a number of comments on this doc, actually. Overall, the draft is very DTMF-specific, and not focused on telephone signaling sent over non-CAS signaling systems (like SS7 or Q.931). The statement in the abstract that all specifications that use any sort of telephone numbering MUST use this document seems too ambitious in this light. I would be much happier if the parantheses in that sentence were removed, and this document were considered to authoritative only for DTMF sequences. First of all, the abstract suggests that GSTN/E.164 numbers are 'dial strings'. This isn't true. Nor are they subsets of dial sequences. There are numerous telephone numbers that are undialable, and that contain non-DTMF elements (for example, the definition of Dial Sequence in Section 2 does not accomodate the hex digits (A...F) used in some number portability schemes - this usage is not coextensive with special DTMF tones A...D used in, for example, American military telephones). E.164 numbers have a maximum length, which dial strings do not. I agree with Allison's comment that compatibility with other uses of telephone numbers in the IETF is not obviously ensured by the 'collection' of the syntax of dialing strings from existing IETF standards, especially since at least one of those standards (i.e. rfc2806bis) is currently a moving target. The tel URI, for example, does allow hex chars to appear in telephone numbers (HEXDIG). The '*' and '#' keys used in dial sequences are not, however, used in GSTN addresses. The syntax given for global-numbers in 3.1 is entirely open-ended (the only stipulation being that the representation is preceded by a '+'), and doesn't even mention the use of country codes, let alone mandate their use in global-numbers (which rfc2806bis does). The first sentence of Section 3, which suggests that DTMF dial sequences are the only way that GSTN addresses can be accessed, is also inaccurate. I think the draft would really benefit from more specification of what GSTN, as opposed to E.164, numbers signify - GSTN numbers are undefined in the document, and the only reference provided is to E.164 (in which the string 'GSTN' does not appear). Do they include nationally-specific freephone numbers (like 8xx codes here in the US)? Do they include service codes (911 or 112)? If so, how should they be represented? There is significant exploration of the representation of these sorts of numbers in rfc2806bis that is not reflected in this draft. In short, I think this document does a good job of representing DTMF dialing sequences. I don't think it is as servicable as way of specifying abstract E.164/GSTN addresses outside of the context of dialing. I would recommend that the document's scope by restricted only to the former, not the latter. Conversely, rfc2806bis does not cover dialing strings, it only addresses identifier representation. I think this is a sensible division between these two documents.