mail-ng
[Top] [All Lists]

Re: Less is more

2004-04-27 06:30:49

Nice to see that the list isn't dead.

On Tue, 27 Apr 2004 22:10, Frode Gill wrote:
One of my hopes for mail-ng is that it will be easy
to implement, and not be forgiving about bad implementations.

The usual principle is "Postel's Robustness Principle", which states that an 
endpoint should be strict in what it sends, but liberal in what it accepts. 
Some have argued (as you do) that this is not appropriate for an application 
protocol, as it encourages sloppy implementation. Take, for example, this 
extract from RFC 3117 (one of the few "philosophical" RFCs out there).

   Counter-intuitively, Postel's robustness principle ("be conservative
   in what you send, liberal in what you accept") often leads to
   deployment problems.  Why? When a new implementation is initially
   fielded, it is likely that it will encounter only a subset of
   existing implementations.  If those implementations follow the
   robustness principle, then errors in the new implementation will
   likely go undetected.  The new implementation then sees some, but not
   widespread deployment.  This process repeats for several new
   implementations.  Eventually, the not-quite-correct implementations
   run into other implementations that are less liberal than the initial
   set of implementations.  The reader should be able to figure out what
   happens next.

   Accordingly, explicit consistency checks in a protocol are very
   useful, even if they impose implementation overhead.

   -- M. Rose, RFC 3117, November 2001, p.16

I believe that it will be appropriate for new application protocols (like 
mail-ng) to heed this advice and be rather less liberal in what they accept.

* Use an easily parsed timestamp (my advise: 64-bit number representing
timestamp and offset from UTC)

I applaud the general principle of "easily parsed timestamp", but there's an 
enormous can of worms waiting to be opened if you want to discuss this in any 
detail. Let's be sure that we know what purpose the timestamp is being used 
for before we discuss the matter in more detail.

* Use one and only one charset (my advise: utf-8)

Does anyone see any major drawback in using UTF-8 only? It is arguably the 
most general and most efficient charset out there for the purposes of 
Internet application protocols, and its use in XML has made it about as 
mainstream as it needs to be. This need not preclude other charsets from 
being carried in mail, but they would be treated as opaque binary data by the 
mail protocol. UTF-8 would be the exclusive encoding for parsed elements.

* Use one and only one content transfer encoding (my advise: 8-bit)

The use of any other transfer coding has generally been the result of design 
limitations in the carrier protocol which preclude 8-bit data (such as 7-bit 
and line-length limitations in SMTP). I applaud the general principle that 
any new protocol (intended to carry arbitrary payloads, like mail data) 
should avoid such limitations by design.

* Use an easily implemented envelope (my advise: xml or xml-lookalike,
with data-size attribute for a scheme identical to IMAP4 literals to
prevent a need for escaping)

Discussion of XML is premature until we have some idea what data we need to 
transfer at particular moments. XML is good for certain types of structured 
data, but there may be better approaches for very lightweight messages or 
heavily binary-oriented messages. Unless we are assuming that mail messages 
will be monolithic MIME-like constructs (as they are now) -- and I see no 
reason to make that assumption -- then we should probably postpone this 
discussion until we've fleshed it out in the abstract a little more.

I would like to have a header specifying the jurisdiction the
email is sent by.

Can you propose a means whereby the veracity of that header can be checked? 
What's to stop a sender from lying? How useful will it really be, relative to 
an independent third party opinion, like "blackholes.us"? I say "nay" to this 
idea, for now at least, unless you have a very cunning plan up your sleeve.


<Prev in Thread] Current Thread [Next in Thread>