Graham Klyne wrote:
I can't resist mentioning
http://www.ietf.org/internet-drafts/draft-klyne-message-rfc822-xml-03.txt
That's a pretty good approach. I like the potential for separating the
transfer headers from the message headers. I also like the potential for a
namespace of fields, since that allows people to develop their own headers
as they wish, without undue fear of conflict. Towards the latter point, I
was considering the use of OIDs for labels, although the ASCII lovers will
probably prefer XML to OIDs.
It seems to me that we should be cataloging the kinds of requirements that
we want from a new message. My bet is that some of these wishes will also
indicate a requirement for a new transfer protocol as well. Some of the
things I would like to see:
o Direct UTF-8 in the header field values (duh)
o Bodies that default to flowed line-wrapping, eg without requiring
fixed line-lengths in the transfer protocol
o Trace-Level header, allowing me to set "0" for "no trace data",
"1" for "errors only", "2" for "errors and warnings" through
"5" for "delivery notifications and everything else"
o Separate envelope/trace block for end-to-end reliability purposes
(envelope corruption is a rare problem but still needs fixing)
o Recursively-signed relay data. EG, the submission server signs
the envelope/trace block after creating the initial data, the
next-hop MTA signs the envelope/trace block after it modifies
the data, etc. The intention here is that the reverse-path data
should be able to be validated by any node in the path.
There are some obvious protocol requirements from the above. Some other
ones that would be nice:
o Need a way to interrupt the message transfer without sending
<CRLF>.<CRLF> sequence or dropping carrier.
o New commands and response codes should be configurable via
namespace identifiers, such as OIDs. Every response associated
with any command should have a unique identifier specifically
for that command/response pair.
o Full-service routing, including remote expansion of local-parts
Some of these are easier than others.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/