The problem is fundamentally one of culture clash. Within the IETF
community, the most important thing to strive for in a protocal is
interoperability. Hence, what we spend a lot of time working on are
standards which explicitly mentionbits and bytes in the protocol
specification. For example, from the PPP Authentication document, RFC
1334:
A summary of the Authentication-Protocol Configuration Option format
to negotiate the Password Authentication Protocol is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hence, when people from the IETF talk about protocols "using ASN.1",
they generally mean either the BER, DER, and perhaps PER encodings of
the ASN.1 specification of the protocols. After all, that's what's
really important.
Within the ISO community, it has always seemed to me that
interoperabilty was not major, driving concern, but being able to
document protocols in an elegant, nice fashion. Hence, the emphasis on
the whole concept of Abstract Syntax *Notation*, the bifurcation of the
notation from the encoding, and your insistence that DER and BER aren't
part of ASN.1
The claim which is generally made is that this bifurcation allows
flexibility, because different people can specify different ranges of a
type --- your example of INTEGER (12345678 -- 12345680) only taking two
bits, for example --- without needing to write a new protocol
specification. However, this is only interesting from a notational
point of view. From a practical, interoperability point of view, it's
meaningless and pointless, since people who aren't using the same
profile of the protocol can't interoperate. But if the important thing
is being able to publish expensive, elegantly notated protocols
specifications, ASN.1 is great!
My claim (and I believe Jeff's claim, although I won't put words in his
mouth), is that most of the interoperability problems that we have had
with Kerberos V5 would have vanished into thin air if we had put used a
protocol notation much like what was used for the IP and PPP
specifications (see above for an example), instead of using an ASN.1
specification, which then forced people try to divine what the wire
encoding of the protocol was from the often obtuse and
hard-to-understand ASN.1 encoding specifications ---- which are
scattered across several hard to obtain, not to mention expensive,
documents.
Furthermore, ASN.1 compilers don't necessarily help in this matter,
either. One of the bugs was caused by a misunderstanding about whether
or not one particular ASN.1 compiler did a bit-reversal in the ordering
of the bit strings when converting the bit-string to an C integer
variable. In other words, the ASN.1 compiler adds an extra abstraction
layer and an extra layer of complexity, and hence adds another place
where bugs can slip in betwixt the specification and the implementation.
- Ted