Re: Less is more

On Tue, 27 Apr 2004 23:30:47 +1000, Brett Watson  
<famous-mail-ng2(_at_)nutters(_dot_)org> wrote:
> 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.
Exactly. And it seems like you understand my point in why this is not a  
good idea for mail-ng... Personally, I would be glad if the mail-ng server  
would be instructed to send non-conforming messages to /dev/null!

> > * 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.
Of course. This is why I give advices, not final sollutions   :-)
If we need an explisit timestamp or not is another question, but please  
don't let us settle for anything like the RFC822 Date-format, and all the  
interesting representations it has gotten in various mail clients, if we  
really do need one.

> > * Use one and only one charset (my advise: utf-8)
> Does anyone see any major drawback in using UTF-8 only?
[snip]
> This need not preclude other charsets from being carried in mail, but  
> they would be treated as opaque binary data by the mail protocol.
I don't see any drawbacks in why it couldn't be the one and only charset.  
[Full stop].

> > * 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.
...which is why I added xml-lookalike. My point is that it will be much  
easier to implement an xml kind of format rather than a MIME one, and I  
want to make sure implementing mail-ng according to spec will be as  
trivial as possible, without putting in too many restrictions.

> > 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?
I expect mail-ng to be digitally signed and encrypted, and not as easily  
forged as RFC822-messages. I also expect mail-ng messages to be legally  
binding. But even if the sender lies, he would have to choose one  
jurisdiction and would be hold liable according to that one. If sender  
choses a very liberal jurisdiction, the recipient will most likely block  
this message as it exceedes the local one. Basically, all I want is some  
way for people to don't risk receiving messages that would be illegal in  
their local domain, and right now blocking all non-whitelisted messages  
sent from America is a quite daunting task. The sollution could be  
something very different than my suggestion, but we have a problem with  
the current protocol, and it should be resolved in the next.

> How useful will it really be, relative to an independent third party  
> opinion, like "blackholes.us"?
A local backholes.us-list would need to be updated very often, and with no  
local list we would need to have a lookup - in which we would get all the  
problems we have with DNS-servers nowadays (TLDs, anyone?). It might be  
one sollution, but I still think it will be more efficient, and easier to  
make legally binding, if this info is embedded into the protocol.
--
Frode Gill