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

On Feb 1, 2004, at 1:49 PM, Paul Smith wrote:

> At 18:58 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.
> > 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. dbf files weren't intended to be a cross-platform network 
delivery interface, XML was. You're actually better off stuffing it in 
a MySQL MyISAM table, because that's built for binary compatibility. 
But even that assumes that the filestore on the far side is compatible 
with the filestore on this side, and I don't want to assume that. XML 
doesn't.
> 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? Sorry, but this is a strawman. And it's one of the 
reasons we're in the situation we are today. Let's not re-impelment 
sloppy data methods becaue it's less work.
> Yes, RFC822 headers are a bit of a mess, that doesn't mean that a new 
> line based protocol would have to be:
> Subject: This is my nice subject\nwith some line breaks in it
> From: myname(_at_)company(_dot_)com, My Name
> To: "Bill(_at_)microsoft(_dot_)com", "Bill Gates"
> To: "elvis(_at_)presley(_dot_)org", "Elvis \"the king\" Presley"
As someone who writes stuff that deals with this for a living, "bit of 
a mess" is like saying it's "kinda dead".
To name just one instance where line-based protocols suck and XML would 
make everyone's life easier:
        Subject: Re: [mail-ng] This is a subject line

Now, parse that out rationally and display it properly in Swedish. Or 
Japanese. or French.
If, instead, it's packaged up in XML:

        <subject>This is a subject line</subject>
        <subject_reply>Yes</subject_reply>
        <subject_tag>mail-ng</subject_tag>

it's trivial to localize that to any language. Plus, an MUA can be 
trivially configured to re-arrange the information pieces. If you are, 
for instance, someone who doesn't like/want mailing list tags in your 
subject line, it's now trivial and unambiguous to TURN THEM OFF, 
meaning there's now no reason not to include them and leave them up to 
the user to show or hide -- ending *that* religious fight forever.
So you end up with:

        [swedish for Subject] SV: This is a subject line

(and yes, I've gone blank on what the "subject" is in swedish. ohwell).

to see why XML is useful, stop thinking that we're going to make a 1:1 
translation of line-based info to XML, and start thinking in terms of 
the meta-data that is attached to a message. Subject itself has 
multiple pieces of meta-data wedged in it. Split that meta data out 
into unambiguous pieces, and give the end-user control of which parts 
to display and how to display it. In fact, now that I think of it, 
subject_tag is probably unnecessary, because the meta-data will likely 
have info on the mailing list embedded in it (the ng of the list-id and 
list-* RFCs) and the subject tag would be generated off of that -- if 
the user wanted it.
> And then someone sends something you'd not seen before and trashes it.
like we don't do that today? At least this way, we have a structure we 
don't have to guess at. it's either well-formed and standards 
conforming or it's not. and if it's not, that's not the receiver's 
fault.
> 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.
Besides, globally, that lowest-demoninator aspect of email has already 
been handed over to SMS, just as the immediacy aspect of e-mail has 
been handed to IM. there's no need to support that kind of simple 
e-mail, because it's already moved to a different protocol, one that 
SMTP interfaces to, and one which the ng system will want to gateway to 
as well.