Re: ::scr avoiding quotation flamewars

[David Cantrell <david@xxxxxxxxxxxxxxx>]

On Fri, Oct 19, 2001 at 07:18:30AM -0700, matt jones wrote:
> Okay, okay, I realise that the way email works isn't b0rken[0] ...
> 
> What about an email format which contains metadata about the content, but
> no set presentation? The mail client could then display this in the way
> the recipient preferred, jeopardy-quoted, interleaved or whatever. Voila!
>
> 1) Is it in any way, shape or form a good idea?

Yes.  Seperating content from presentation is Good.

> 3) Is this reinventing something?

Maybe XML and/or CSS the way they were originally intended.

> 4) How would you do it, presuming you would?

We need to minimise bandwidth/disk/CPU usage* and also avoid interoperability
problems with the ENORMOUS base of RFC822/RFC2822 etc compliant clients.

* - consider the overhead of running a 500,000 user mailing list, and
providing archives and digest versions.**
** - experimenting with interspersed footnotes :-)

We achieve the latter by including both a plain-text version and some
super-whizzy stuff using MIME magic.  I suggest that the plain-text one
use "proper" quoting, like what I use, as that *is* the published
standard, it is readable by everyone, and no-one argues vociferously
against it.  Of course, users can attach other stuff too just like we
do today.

Now, how to construct the super-whizzy stuff.  It needs to contain
information on the structure of the text (who wrote what when in reply
to whom), and we may include information on formatting (eg fonts,
bold, italic, colours ...) and a definition of how the author would
view it.  what we absolutely shouldn't do is allow it to contain code
detailing how to unwrap and display itself, or any macro capabilities,
for obvious reasons.

To conserve bandwidth, CPU, and disk we should avoid replicating the
body text in the super-whizzy bit.  Instead, it should contain only
markup.  Where the text would be in (eg) XML, we replace that with
pointers to the appropriate start and end points in the text.  Make the
pointers 20-bit, allowing for a maximum body size of 1Mb.  This is more
than enough - anything even approaching that big should be in an
attachment.  I did consider making them 16-bit, but that is too small
for a few legitimate plain-text messages I have received.  You might
want to optimise the pointers away for *really* short sections of text,
but I doubt it would be worth it - the tiny tiny saving would IMO be
outweighed by the increased software complexity.  I'm not going to say
whether the markup should be XML (or some other text-based markup) or a
binary format, but if it is XML then it should be compressed using (eg)
zlib.

It is up to the user - in conjunction with his MUA, of course - to
determine how this stuff should be interpreted.  There are arguments to
be made both in favour of and against the standard pre-defining a few
choices for each option.  If there are standard choices, then it is
trivial to attach the sender's preferred rendering instructions too,
otherwise such information can only make sense to someone using the
same client - a rare occurrence - and so should not be catered for by
the standard.  My gut tells me to leave this sort of thing to the MUAs,
as they can be customised by savvy users with source code or scripting
languages, and for the proles their vendors can react to demand for
new rendering features quicker than the IETF.

</EORFC>

-- 
David Cantrell | david@xxxxxxxxxxxxxxx | http://www.cantrell.org.uk/david

   The voices said it's a good day to clean my weapons