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

[Claudio Allocchio <Claudio.Allocchio@garr.it>]

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