At 09:03 04/02/06 -0800, Paul Hoffman / IMC wrote:
Set C:
+ mixed parts
: marked for human consumption
: marked for machine consumption
I think this is the simplest way to express things.
But I would like to see many more requirements/examples for
interesting applications, interesting message content,...
so that we get a better idea of what we need in terms
of generic capabilities for message formats, and requirements
on the underlying transport, as well as hopefully some new
and exciting functionality for the users that will make it
worthwhile switching to the new system.
Currently, I like Set C the best because it seems that something that can
read the body can read the markings and decide what to do with it.
One thing I'm not clear about is whether it is possible to make
a strict distinction between human consumption and machine
consumption.
Let's pick a single example:
Users would like to do scheduling and meeting planning using
email. This includes:
- Sending a mail to a group of people proposing a meeting
- Replying to that mail confirming the time or proposing other
times.
- Receiving meeting time and place and being able to read that
in email as well as having it go into the recipient's calendar
at minimal effort (e.g. one click).
Can this and similar things be done with one part for human
consumption and one part for machine consumption? Or is it
better to have a single part with structured information
and some extensible architecture to display that to the
recipient? Or may we need or benefit from some new ways
of combining free-form plain-text information and structured
machine-readable information?
It is completely clear that whatever we define has to be extensible
because we can't know what users in the future of what we define will
want. The question is how much we define initially, and how the extension
mechanism works.
Very much so. I guess having more examples of the things users
would like to do would help us get there (or closer at least).
Regards, Martin.