Re: Use of XML as a basis for e-mail

----- Original Message ----- 
From: "Chuq Von Rospach" <[email protected]>
To: "Jacob Palme" <[email protected]>
Cc: "Chuq Von Rospach" <[email protected]>; <[email protected]>
Sent: Monday, February 02, 2004 12:06 PM
Subject: Re: Use of XML as a basis for e-mail


> > This example clearly shows one disadvantage with XML, it
> > requires approximately twice as much space for the same
> > information as ABNF as used in e-mail.
>
> and given that we're going to be attaching a 20K html part and a 250K
> jpeg graphic of the kid's birthday -- who cares? Keep it in perspective
> with what's being sent via email these days and where email is going.
> Rich content. In 1975, headers were 40-50% of an average message. Now,
> if they're 2% I'd be amazed (I haven't analyzed it in a while).

I agree with this (not necessarity the numbers) but the principle. I will
say that mail quoting is a much larger part these days with the mail
bandwidth, especially the form of reply behavior where people reply at the
top (no inline quoting, commenting) and simply keep addending the mail
thread.   Not a  big issue for direct mail, but mailing list, news, etc.

This in-directly brings up an issue of the "message-id",  its purpose.

Once upon a time, an "other network" going thru the same process of coming
up with the "ng" system,   a major debate developed over the interpretation
and purpose of the message-id:.   Is it for tracing or for dupe processing?
or both?

The "other network" basic requirement (as defined by the author of the
specification) was:

         - "Uniqueness" at the originating server only

with no strong format to be used.  A recommended format was showed using an
example based on the "network" at the time
(serializedcounter/hash@serveraddress),  however, the spec design goal was
mosting for "server side dupe processing" using whatever format you wanted.

However, the question rised was whether another system use this "tag" for
distributed mail dupe processing as well:

          "sorry, this message was already received"

and a question of whether it was usable for Direct mail vs Public Mail or
both.

As we know,  in current "public mail" conference networks, such as NNTP,
the message-id is used for dupe processing.

Current BCP is that it is NOT used for dupe processing for Internet EMAIL.

The "other network" had the Internet "monkey" hanging on its back as an
emerging standard,  so this helped making a stronger case for dupe
processing across the network.  But this would of required a change to the
specification so that the format defined uniqueness across the network.

>
> Or we simply define a message envelope that includes the ability to
> define parts outside of the XML part that support BLOBs. There are lots
> of options here, depending on whether we decide to keep everything
> inside XML, or choose to attach certain things outside the package;
> both have their advantages and disadvantages.

I personally believe if XML is considered, that it would be used as a
"wrapper" concept because as it was the case with  the internet RFC 822
emergence as the new standard,  there will be a big emphasis in the
"gateway" market to make it all possible.    We can not assume that everyone
immediately will change their systems to the new format.  Converters will be
written as the most feasible way to implement or integrate into the new
system or network.

So for example, an XML wrapper can be used to identify the "data format" the
"network," etc, NG-MAIL specific network control information.  This will
help enhance the acceptability concept for the new stronger, more secured
NG-MAIL as a transport system that is basically data format independent.
It will also help mail processors by including data streaming XML
attributes.

This was the way other system dealt with the problem of how to best fit
everything together.   The key difference was,  besides the fact it predated
XML,  it used a binary wrapper with an initial standard set of numeric field
tags to address the concern of overhead,  which of course, is where I would
agree with you would not be a big concern today.  But it is worth a
consideration.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com