At 03:07 PM 5/3/02 -0500, Eric A. Hall wrote:
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:
[long and varied list snipped]
I was once involved in a messaging project to deploy a wide range of
similar features in a monolithic protocol loosely based on Internet mail,
which turned out to be a not-very-effective [*] way to proceed ([*] British
style understatement ;-).
It seems that in an Internet context, it's far easier in most cases to make
progress by tackling the problems individually, and within the constraints
of email architecture and practice. There are a very few problems which
are sufficiently hard to be practically impossible to do this way (e.g.
some of the requirements for instant messaging), some which permit coherent
designs but uncertain deployability (e.g. content negotiation for Internet
fax) and many for which workable solutions clearly do exist.
But mainly, I think most requirements are not fundamentally limited by the
message format in Internet mail.
Internet mail is an important application, and current protocols generally
work very well for that application. But I think not every application
that looks vaguely like mail is a good candidate for use of SMTP (just as
not every application that looks a bit like a request-response interaction
is an ideal candidate for HTTP).
Regarding your list of requirements, I'd suggest not lumping them all into
a single wish-bag. I prefer to find architectures that allow one to
separate concerns; the RFC822-XML proposal started out as an attempt to
leverage the experience with RFC822 to create a piece for use with instant
messaging. As it happens, it hasn't been adopted there, but was used in a
prototype message archive development. A solution that tried to tackle too
many problems at once probably wouldn't have been useful.
Which is roughly where I started above.
#g
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>