On Tue, Feb 08, 2000 at 05:09:25PM +0900, sen_ml@eccosys.com (sen_ml@eccosys.com) wrote:
>
> if there is no method of dealing w/ this intelligently, i think some
> mechanism should be designed.
>
> i would like to hear the opinions of other users of gnupg/pgp as well.
Several friends and I were debating the other day about the gains and losses that would be imposed if the entire Sendmail-based email system as we know it were scrapped for an XML-based system. This is purely hypothetical, as a complete replacement of the entire Internet email infrastructure as we know it is practically impossible, but I would categorize this solution to your problem as one of the benefits of switching to an XML-based email format.
Example:
<?xml version="1.0"?>
<email><body subject="Catching Up"><greeting>Dear <recipient address="mom@aol.com">mom</recipient>,</greeting>
<para>Things are going well here. How are you?</para>
<signature>Love, <sender address="bob@vanitydomain.com">Your Son</sender></signature>
</body>
</email>
This example shows how header information (including the subject line) could be used within the content and extracted with any of the popular Free xml parsers available.
Another example shows how header information could be abstracted from the content:
<?xml version="1.0"?>
<email>
<recipient address="mom@aol.com"/>
<sender address="bob@vanitydomain.com"/>
<body subject="Catching Up">
Dear Mom,
Things are going well here. How are you?
Love,
Your Son
</body>
</email>
Now, add encryption: say instead of using arbitrary ---- BOBS ENCRYPTION EMPORIUM ENCRYPTED MESSAGE FOLLOWS ----- tags, like PGP and GPG do, an encryption program would only have to read text between user-selectable tags and add tags of its own:
...
<email>
<recipient address="mom@aol.com"/>
<sender address="bob@vanitydomain.com"/>
<encrypt>
<body subject="Catching Up">
Dear Mom,
...
</body></encrypt></email>
Note that by choosing to put the "encrypt" tags around the part of the message with the subject specified, the subject would be encrypted with the rest of the message when the time comes to convert to cyphertext. However, since it is still specified in machine-parsable XML tags, when the secret key is used to decrypt the content of the <encrypt> tags, it can still be rendered as part of the MUA header info if the user desires.
Obviously, this level of flexibility means it'd be easy for people to write email that utterly breaks the transport system; for example, what if the user chose to encrypt everything within the <email> elements? The recipient and sender addresses would be encrypted also and the MTA's would never be able to deliver it. This seems to be more of a problem for MUA developers, though, rather than with the concept as a whole. Those of us who understand XML and would probably prefer to write it by hand would simply have to be careful to exclude transmission attributes from the <encrypt> elements.
XML's greatest feature, I would say, is its ability to be parsed meaningfully by machines as well as humans. This would make it well-suited to digital signing, too:
<signed>Message text blah blah blah including markup like <subject>this is the subject</subject> blah blah blah</signed>
<signature>ghlasj;dfklaertoainsertcyphertextherentmr,ewhuopashjldnbt</signature>
...and if the mail user agent understands the specified DTD (which could be different for PGP 2, PGP 5, GPG, and Proprietary Encryption Software #273, thus making incompatibilities irrelevant) it could do neat tricks like hide the ugly signature cyphertext but display the contents of the <signed> tags in black if the signature is valid and red with a warning dialog box if it isn't.
Once again, this is all purely hypothetical and even a bit oversimplified, but selecting which parts of email documents get treated which ways by which mail agents seems to be a task that the flexible, hierarchical Extensible Markup Language would excel at.
This message has contained YASXMLT (yet another stupid XML trick).
--
Everything on television is fake.
----------------------------------------------------------------------------
sungod@atdot.org
