Nathaniel,
Certainly, Mime offers an adequate base for acks, etc. My hope is that
we can add a proper framework for control messages, rather than
doing things entirely piecemeal.
Personally, I expect read-ack to be the most useful, too, tho I do
hope that delivery-acks could be made to work, since I would dearly
love to have end-to-end acknowledgements of delivery.
My suggestion is that a major content type of "Control" be added,
with subtypes of "Sender-MHS", "MHS-MHS", "MHS-Receiver", and
"Sender-Receiver". (I've no religion about the vocabulary, per se.)
If we really view these as protocols, then we need to capture the
Request/Reply status and this could be done either through
the major type (Control-Request vs. Control-Reply) or the subtype
names (e.g., Sender-MHS-Request vs Sender-MHS-Reply), or as a parameter
of the subtype. SNMP uses the middle style. While it creates 8
subtypes, I lean towards it, somewhat.
Hence, your own mechanism becomes "Control/Sender-Receiver-Request:
action=read-ack" which returns a "Control/Sender-Receiver-Reply:
action=read-ack".
Please note, I'm suggesting we take a bit of time and develop a clean,
extensible framework, but not a particularly elaborate one. Then we
can a) think quite a bit more clearly about specific functions, and
b) add them cleanly. Stuffing everything into a type of Application
strikes me as not scaling very well.
Dave
P.S. Wicked thought: Would it be useful to have application/snmp?
d/