Intelligence in standards-based software

IETF has a set of "golden rules". The two most well-known
rules are:

(1) Be conservative in what you send, liberal in what
     you accept.

(2) Do not munge (= modify information objects you
     are just transferring)

I am beginning to understand that there is a need for
a new golden rule:

(n) Do not specify standards which require any kind
     of intelligence of the software using it.

One example which shows the importance of this new golden rule is the
problem with multipart/alternative and different body parts
containing the same text in different languages. Such use of
multipart/alternative is correct according to the MIME standard (RFC
1522, RFC 2046) only says that this are different alternative
renderings of the same information, but does not say what the
difference is. The receiving mailers must then analyze what is
different between the body parts, in order to find out which piece is
best according to the needs of a particular user. And to make this
decision requires more intelligence than is reasonable to expect of a
mail software. Much less intelligence is needed if the "difference"
attribute to multipart/alternative is used (that attribute is
specified in RFC 1766

As I have poisnted out in previous messages to this mailing list,
such use of multipart/alternative causes disastrous problems with
many popular existing mailers. The original MIME standard did not
have the "difference" attribute
Jacob Palme <> (Stockholm University and KTH)
for more info see URL:

Received on Wednesday, 2 May 2001 13:40:35 UTC