Re: draft-allocchio-gstn-05.txt concern

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Well, given your statement that your specification shouldn't be
applied to LDAP telephone numbers AND an IESG member commented
stating that your I-D defines the "preferred" syntax for telephone
numbers in comment to a recent LDAP draft, implies that your
I-D is not as clear as it should be.  Like the IESG member, I
read your specification as applying to telephone numbers in
general (though defining syntax capable of supporting additional
dial sequence capabilities).  I think the I-D needs to be clarified
here.

As far as the applicability of your specification to
future specifications, I argue that is a matter for
the authors of future specifications to determine.
The "MUST" (as defined by RFC 2119) is an implementation
imperative and hence is misused in the sentence below
as doesn't apply to implementations of this specification
but to creators of future specifications.  I believe my
concerned are consistent with ballot comments by Thomas
and Allison.

Kurt


At 08:13 AM 5/17/2003, Claudio Allocchio wrote:
>On Fri, 16 May 2003, Kurt D. Zeilenga wrote:
>
>>    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.
>>
>> as this is quite unusual for a technical specification to
>> mandate its use in all future technical specifications.
>
>Well, no. It is implicit in all specification which are intended as a
>"helper specification" that they should be used by other specification,
>otherwise they have no reason to exist. A very evident case is ABNF, which
>is helpful only if the other specifications use it.
>
>
> Those
>> kinds of mandates are commonly left to BCPs (where imperatives
>> refer to IETF progression of future works).  I suggest this text
>> be reworded to avoid the use of an implementation imperative
>> here (as keywords are defined here).
>
>The scope of this "helper specification" was defined while discussion
>originally if and how to make it, and even if it is of course the IESG
>task to have the future specification be coherent with this notation
>(which refers exclusively to dial strings, please note!), we decided to
>note it down here. In fact it is easier to have it already written down,
>thus editors can get the message already, than have all specification
>reach the IESG, and then the IESG tell back, "sorry, please rewrite
>accordingly to this helper spec, thanks."
>
>
>> The I-D then continues:
>>    The specification was collected directly from Dial
>>    Sequence definitions which are already described in
>>    existing Standard Track specifications (such as [3]
>>    [4] [5] [6]) and is fully synchronized with them.
>>    Full compatibility is thus assured, and, as a consequence,
>>    this specification results in a compendium of
>>    existing definitions.
>>
>> It is unclear to me whether the author considered the LDAP
>> specifications for Telephone Number and related E.123-based
>> syntaxes defined in RFC 2252 when engineering this work.
>
>I made a very expensive search on all existing specs, but of course I
>could have missed some. I considered, however, RFC2252, and that does not
>apply. In it you define "telephone numbers" (and correspondent fax
>numbers) in directories. my specification explicitly states that it DOES
>NOT represent thelephone numbers, and their abstreact addrressing
>notations E.164 (and E.123), also because there are elements which are NOT
>diallable, and thus not representable in a dial string.
>
>Thus we are talking of two items different in nature. If a telephone
>number represented into a directory attribute needs to be passed along an
>application as a dial string (for example into an e-mail address) then it
>is converted into a dial string and uses the proposed syntax. Already in
>other standard (the fax ones for example) we considered using E.123 as a
>syntax, but we decided not to do as it proves too complex and may create
>incompatibility requiring complex encoding to be used inside e-mail or
>other service addresses.
>
>  Hence,
>> I've very leery of a mandate that would require future LDAP
>> specifications to reference this new specification.
>
>If the specify a dial string... not a telephone number abstract address.
>
>(personally I think E.123 and E.164 were yet another mistake by ITU. They
>had very poor ideas about compatibility problems in "real applications"
>carring along the Internet addresses, and thus prepared a very human like
>syntax for telephone numbers, which is very problematic to implement in
>ASCII based Internet protocols and related applications. I was (one of the
>many) who did the specification of the gateway between ESMTP and X.400,
>and we had to write an RFC about 130 pages long... one of the reasons: the
>unduly complex quoting mechanisms specification to pass into ASCI based
>protocols what CITTT (ITU) specified into very human oriented addresses
>and parameters...
>
>:-)
>
>regards
>Claudio