Subject: Re: User Petition on Standards to Netscape and Microsoft

From: Rowland Smith <[email-masked]>
Date: Wed, 31 Dec 1997 09:48:37 -0500

>To: Chris Newman <[email-masked]>
>cc: Christian Huitema <[email-masked]>, [email-masked]
>reply-to: [email-masked]
>Subject: Re: User Petition on Standards to Netscape and Microsoft 
>Date: Tue, 30 Dec 1997 13:55:47 -0800
>From: Marshall Rose <[email-masked]>
>
>> > I would advocate that IETF standards should never use ASN.1.
>> I concur.  We have ABNF (RFC 2234) for representing syntax, and it
>> encourages textual protocols.  Textual protocols can be debugged with
>> off-the-shelf or free network snoopers and telnet clients.
>> ...
>
>thank you for a very concise statement of the solution.  while ASN.x has
>its uses, i think it is fair to say that its pain has, regrettably,
>outweighed its gain in the Internet space.  this may not be true in
>other spaces, but there is a clear preponderence of the facts from the
>ietf perspective.
>
>/mtr

What "preponderance of the facts from the ietf perspective" are you
referring to?

Later,

Rowland Smith
[email-masked]

---

From: Marshall Rose <[email-masked]>
Date: Wed, 31 Dec 1997 10:25:20 -0800

> What "preponderance of the facts from the ietf perspective" are you

go back and read the messages sent by christian, chris, bill, karl, et. al.

those who forget history are doomed to repeat it...

/mtr

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 31 Dec 1997 15:59:50 -0500 (EST)

I recommend reading RFC 1958 and draft-newman-protocol-design-01.txt.  People
might also look at <http://www.clark.net/pub/cme/P1363/asn1.html>. 

Note that those supporting ASN.1 tend to be those who particularly venerate
standards becasue they are standards, those who are particularly steeped
experts in ASN.1, and those who make money from it.  These categories overlap
and I certainly don't want to imply any sort of dishonesty or impropriety in
such supporters.  The way things look depends on where you come from. 

On the other hand, it has been my consistent personal experience in talking
with implementation engineers that over 90% of them on occasion refer to
ASN.1 as "assinine one" and consider it at best to be a heavy burden than has
been forceably imposed on them by an outside power.  If your goal is to
create interoperable implementations, this also implies a particular view,
one not favorable to ASN.1 and its plethora of versions and encodings and
options, the continuing necessity to consult arcane, expensive, and
relatively difficult to access formal standards documents, impetus to use
special compliers that end up controlling the memory strucutres you use,
etc., etc. 

To the extent that the IETF wants to cater to professional standards writers
and meeting attenders, ASN.1 may be the way to go.  But to the extent that
the IETF wants to get easy to implement interoperable instatiations of its
standards deployed, ASN.1 should be countenanced only when the existing
fielded code base overcomes its disadvantages or there is some other special
reason for taking on the weight and complexity it saddles you with. 

Donald

On Wed, 31 Dec 1997, Marshall Rose wrote: 

> Date: Wed, 31 Dec 1997 10:25:20 -0800
> To: Rowland Smith <[email-masked]>
> Cc: [email-masked]
=====================================================================
Donald E. Eastlake 3rd     +1 978-287-4877(tel)     [email-masked]
   318 Acton Street        +1 978-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.privacy.org/ipc

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 Jan 1998 22:16:08 +0100

Regarding ASN.1 and textual encodings, it might be helpful to
distinguish the on-the-wire format and the definition language.

For the on-the-wire format, there seem to be three versions in active
use:

- BER (basic encoding rules): the on-the-wire format is largely
self-describing in terms of data types, i.e., even without a spec, you
can guess parse the format and tell whether the bytes are integer or
text. I wrote a relatively simple parser for this which succeeds with
"disassembling" certificates. Used for SNMP.

- DER (distinguished encoding rules), roughly the same as BER minus all
the options, i.e., there is exactly one way to encode an integer of a
certain length, not a basically infinite number as in BER. Used for all
things cryptographic (PKCS stuff), except of course PGP, which doesn't
use ASN.1 at all.

- PER (packed encoding rules) are completely opaque, i.e., without the
spec, all you have is a meaningless bunch of bits. If you want to add an
optional field to the spec, you need to modify the spec and make it
available. (I'm not sure what happens if two people independently want
to add an optional field. Will they collide?) For no good reason, PER is
used in H.323. PER is the most compact of the three forms, but for
almost all application-layer protocols which have any amount of textual
information, this is largely irrelevant (see earlier notes in this
discussion). PER comes in at least two flavors, aligned and unaligned,
depending on whether fields are byte-aligned or not, with various other
options.

In case this requires elaboration, textual protocols such as the MIME
variations (RFC 822-style as in MIME, NNTP, HTTP, RTSP and SIP) are
"above" BER in terms of descriptiveness: the on-the-wire format contains
not just the value, but also the parameter name. This has two
consequences:

- It is easy to add things in a backward-compatible way, since parsers
will skip parameters they don't know. Thus, for example, an ancient mail
reader will not break when it sees a Content-Length header field. I
believe that this has been very useful in the case of protocols with
long histories like email or rapidly evolving ones like HTTP.

- Even without formal specs, the recipient (or rival company) can take a
good guess as to what a header means. This has worked reasonably well
for email headers.

It used to be the case that every text protocol pretty much did its own
thing (IMAP is the worst offender, but the recently RFCified superfluous
dictionary query protocol another), so that there was no possibility of
re-use of parser code. With a
bit of discipline on the part of the spec writer, this does not have to
be the case. It would be nice to have a generic "MIME-like syntax"
definition (basically, "parameter: value ;modifier=value [...]" with
escaping and quoting rules), but it is relatively easy (done that, ask
if interested, end of shameless
plug) to build a parser that can handle most all of MIME, HTTP, RTSP and
SIP,
and related protocols with minimal hassle for each additional protocol.
Having a common meta syntax like a formalized MIME convention also
avoids having to go through ABNF for each new protocol.

Textual protocols, at least of the MIME variety, work well for encoding
the equivalent of SEQUENCE OF with optional elements, where each element
is either a single value, a list or another SEQUENCE OF. It does not
work well for more deeply nested structures. For those, things like XML
or Lisp-ish structures (as in some of the HTTP content negotiation) can
encode any nested structure. At least in the development of RTSP and
SIP, this lack of deeply nested structures not been a major handicap, 
as we divided things requiring nesting (using a separate session
description language like
XML-derivatives or SDP) and those that don't (the requests and their
parameters).

As long as you are not artificially restricted by assumptions about
7-bit transport, as in MIME, carrying moderate amounts of binary data
like certificates is easy, with (e.g.) URL escaping for CR and LF.
Similarly, internationalization with UTF8 or UTF9 is no more difficult
than with the ASN.1 BMPString.

For application protocols, it is also useful to distinguish between
signaling protocols that set up other communications transparent to them
(ftp, HTTP, SMTP do this in-band, RTSP and SIP out-of-band) from actual
application-layer data transport (RTP as one example). For signaling
protocols, the control overhead better be a small fraction of the data
carried/signaled, so that the efficiency of textual vs. binary makes no
difference, even though it tends to be very small in practice. As was
noted earlier, for application-data transport we usually have better
type-specific encodings (GIF, JPEG, MPEG, etc.), none of which use
ASN.1.

One of the strengths of the Internet application protocols is the
ability to program functional subsets and filters in scripting languages
like Perl, Tcl and Visual Basic. Writing a mail filter in Tcl and Perl,
for example, is easy - imagine trying to do this for a PER-encoded email
transport.

Finally, all of the successful binary Internet protocols (with the
possible exception of SNMP) use very simple structures (structs with
fixed-length elements or TLV lists) that would not benefit at all from
ASN.1. [Foolishly stepping outside his area of expertise, from stage
left:] All of SNMP could have just as easily been coded in XDR; one
could argue that the interest in HTTP-based network management is one
indication that even here, simplicity matters.

Henning

---

From: Chris Newman <[email-masked]>
Date: Mon, 05 Jan 1998 16:12:52 -0800 (PST)

On Thu, 1 Jan 1998, Henning Schulzrinne wrote:
> ... Used for all

One might suggest that this is part of the reason we're having so much
trouble getting cryptographic stuff deployed.  FWIW, I suspect I'd have a
much easier time getting triple-DES, DSA and SHA working than the PKCS and
ASN.1 stuff.

Also, don't forget SSH (draft-ietf-secsh-*).  It has one of the simplist
and cleanest binary encodings I've ever seen (including the multiprecision
integer stuff).

> re-use of parser code.

IMAP was the first textual protocol designed to permit multiple commands
to be in progress at the same time with interleaved results.  This
required a new design.  I note there is a newer textual protocol which
added this feature as an afterthought and is now significantly more
complex than IMAP.

> like certificates is easy, ...

Yes.  The "literal" syntax in IMAP/ACAP is a good model for doing so and
it fits nicely into either a line-based or stream-based parser.

> than with the ASN.1 BMPString.

Please don't promote UTF9 by mentioning it as if it might be useful.  I
think ASN.1 has amply demonstrated how confusing multiple encodings can be
and how each additional one makes things worse.  The IETF has only one
recommended character encoding for i18n: UTF-8.  Please keep it that way.

		- Chris