Subject: RE: Protest: Complexity running rampant

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Feb 2007 06:45:38 -0800

I don't think this is an issue worth objecting to.

Complexity exists at many levels. There is complexity of specification and complexity of implementation. The two are not the same.

I can imagine two reasons why I might want to have ASN.1 in XML. The first is that I want to use a single set of tools for data serialization and unpacking. This is particularly attractive if I was going to use an ASN.1 structure inside an XML packet. The second is if I was looking for a way to move from a legacy ASN.1 base to an XML base. 

As far as complexity of architecture goes neither ASN.1 not XML are to my taste. ASN.1 looks like a briliant idea that went into committee and got broken by a few participants whose political skills exceeded their technical skills. This is a real problem in data formats since they appear to be simple enough that everyone can have an opinion. 

ASN.1 is not so bad unless you have to either use the seriously derranged DER encoding or deal with some of the later additions to the data model. DER would not have been so bad if they had chosen to use indefinite length encoding for lists rather than definite length, thus requiring implementations to chose between unnecessary recursion and unnecessary memory copies.

I recently wrote an ASN.1 unpacking routine in Javascript in a few hundred lines. It is not that difficult (packing is another matter - ugh!).

XML syntax is not that bad either. The problems are mostly due to XML schema which makes the unfortunate mistake that C++ made of not jetisoning the all cruft from C and starting fresh. The prefix scheme is neither necessary nor convincing in my view. It breaks the principle that the choice of modular decomposition in a design should not constrain the end result.

In other words the fact that XML Encryption is built on XML Signature should not be visible when reading a document that is based on both.

I don't see that the 'complexity' of XML or ASN.1 is unreasonable though. The problems come from issues such as modularity and version control that have always been tricky. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 27 Feb 2007 23:43:31 -0800

Hi -

> From: "Hallam-Baker, Phillip" <[email-masked]>
> To: "Harald Tveit Alvestrand" <[email-masked]>; "Fred Baker" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, February 27, 2007 6:45 AM
> Subject: RE: Protest: Complexity running rampant
...
> DER would not have been so bad if they had chosen to use
> indefinite length encoding for lists rather than definite length,
> thus requiring implementations to chose between unnecessary
> recursion and unnecessary memory copies.
...

There's a third approach that can be simpler to implement and
faster to execute - do the encoding *backwards*, starting at the
end of your buffer.  Then you don't need to encode the length
(and length-of-length) fields before you know their values.  That
way one can do the encoding without recursion or unnecessary
copies, and ensure that all lengths are minimal.

Randy