Re: What I see as problems to solve ... and a strawman solution

At 23:06 01/02/2004, Chuq Von Rospach wrote:
>>>No, but the point is, XML is a way to distribute that information in a 
>>>way that is unambiguous (you can't mistake a header for a body, you 
>>>can't mistake a subject line with a from line
>>
>>Assuming it's well formed XML.. Oh, the same can be said about RFC822 
>>headers..
>
>If it's not, you reject it, and should. And I think the standards should 
>make that explicit, since the e-mail is littered with problems caused by 
>us building systems that tolerate "legacy issues" in an attempt to do the 
>"right" thing. if we're starting over, let's not let sloppy coding enter 
>the system in the first place this time.

That was one of the items on my initial 'wish list' :-) I think, whatever 
system is decided on, it should be 'well formed or rejected' by EVERYTHING. 
That will force everyone to make it well formed. It could apply just as 
well to existing RFC 822 headers as to XML ones.

The trick is to make it easy for anyone to do it right. Personally I don't 
think XML is the way to go for that. But, the decision of "XML or plain 
text" is a decision for much further down the road. I don't think any USER 
would care. I doubt most administrators would care. All they want is for it 
to work.

>>>and processing those headers. Plus, there are zillions of tools that can 
>>>be used to generate, read and process XML
>>
>>Lots can read DBF files - why not use those?
>
>shrug. because it assumes a storage model, and I think we should avoid that.

I was being sardonic. Saying 'lots of tools support xyz' isn't a good 
argument to use it.. Lots more tools support C than PHP, for instance. But, 
I wouldn't usually write a web page generator in C.

>>I could write a complex XML parser, or I could write a simple line based 
>>parser. I know which I'd prefer..
>
>But what's more important, building a system that functions well, or is 
>easy to program?

Both. I don't think one precludes the other. If you make it hard to 
program, less people will do it, and it'll take longer to be adopted.

>>Don't assume that everything has the power of a modern mobile phone. 
>>Simple mailing needs to be possible with a minimum of complexity - that's 
>>one of the reasons SMTP became popular when other systems didn't.
>
>so you argue that we should gut email to the lowest possible level of 
>capability? Sorry, I don't buy that. It's not the 70's any more. let's not 
>try to take mail-ng back there -- because it'll be rejected in the market 
>if you try.

No, I think it should be POSSIBLE to send a BASIC message with a minimum of 
complexity. It should also be possible to send a more complex message 
without much more complexity.

Binary data transfer, lack of dots, UTF8, sender authentication 
reliability, are all relatively easy to do even for a basic computing 
system (binary, lack of dots is probably easier than SMTP is now, UTF8 is 
zero cost in most simple cases, sender authentication is a bit costly, but 
doesn't need to be too bad); XML, certificates, SSL, etc aren't.

I don't see that XML gives big enough gains for such a big addition in 
complexity.

This is the wrong time in the discussions to be talking about data 
protocols in any case.


Paul				VPOP3 - Internet Email Server/Gateway
[email protected]			http://www.pscs.co.uk/