Re: Less is more

On Tue, 27 Apr 2004 23:30:47 +1000, Brett Watson  
<[email protected]> 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