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

From: Peter Furniss <[email-masked]>
Date: Mon, 29 Dec 1997 16:00:50 -0000

> As to S/MIME, I respectfully request that all references to ASN.1 be
> removed.  Most of the definitions can easily be re-cast in our own RFC
> BNF-style syntax.  There would be no changes to bits on the wire.

You might (or might not) like to have a look at RFC 1698 which gives the 
octet sequence encodings arising from the ASN.1 definitions in OSI ACSE and 
Presentation protocols. That didn't use BNF because it seemed desirable to 
have semi-explicable "magic numbers", though I now don't think it was the 
ideal solution. Since interworking with implementations that had used 
compilers was essential, the "re-specification" as octet sequences had to 
allow some way of indicating how received encodings could differ (due to 
the large number of encoding options in BER). In fact this would probably 
have been better done by including the ASN.1 itself or a BNF form.

If S/MIME (or anything else) is respecified from ASN.1 to octet sequences, 
it is obviously vital to be clear on the relative status of the old and new 
specifications, and what interworking is hoped for. With RFC 1698 it was 
clear the ASN.1/BER specification (in the ISO standard) was definitive, and 
the octet sequences were advisory ( but, I hope, right - and they have been 
shown to interwork with independent implementations).

Peter Furniss

--------------------------------------
Peter Furniss Consultants
58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK
Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy)
Email           : [email-masked]   << note change (9/97)

---

From: Karl Auerbach <[email-masked]>
Date: Mon, 29 Dec 1997 13:06:16 -0800 (PST)

> Presentation protocols.

RFC 1698 is highly restrictive.  It isn't even adequate to represent SNMP
packets. 

RFC 1698 also makes assumptions about the range of data values -- for
example, it assumes that all items will bear only a single tag value
(ASN.1 allows two tags per item) and that the numeric value of that tag
will be such that it uses the single byte encoding format for tags.

Moreover, it imposes restrictions on encoding methods.  For example, it
says that one must use one of three forms for the encoding of length
fields.  A receiver who depended on exactly those three forms would find
itself in the land of non-interoperability if faced with packets which
were encoded by a machine that did optimum packing of the length fields
(as would typically be the case with sending machines using ASN.1/BER code
coming from a good compiler.)

As an indicator of the problems with ASN.1 and BER -- I notice a typical
ASN.1 encoding mistake embedded right into the text of RFC1698 -- On page
8 it says that a integer value of 255 can be encoded into one octet.  That
is wrong.  That value requires at least two octets, otherwise it
represents a negative number.  This is typical of the problems which arise
due to ASN.1 and BER. 

		--karl--