Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses
RFC 3601

Note: This ballot was opened for revision 05 and is now closed.

(Thomas Narten) Discuss

Discuss (2003-06-17)
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

Comment (2003-06-17)
No email
send info
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.

(Bert Wijnen) No Objection

(Alex Zinin) No Objection