|
Re: What I see as problems to solve ... and a strawman solution
2004-02-02 03:57:09
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
support(_at_)pscs(_dot_)co(_dot_)uk http://www.pscs.co.uk/
|
|