I think that this argument needs a realworld application to give it some
bite. I really don't think that there is appreciation for the problem facing
application developers who are looking at possibly using a XML
representation for their object, but are frustrated with the current MIME
definition for the XML content type.
Paul Hoffman wrote:
I tend to lean towards "every application gets a new media type".
Paul understand the calendaring and scheduling application about as well as
any outsider to this application domain. I agree with his note that argues
that the MIME header needs to provide cues to application-specific client
agents (e.g., Calendar User Agent) that periodically peeks into the MIME
entity bucket (e.g., inbox) to look for it's application specific messages.
This is the paradigm that mail-enabled CUAs use today.
However, just having a "calendar" media type won't cut it. The CUA needs to
be able to search the MIME entity bucket for particular types of "calendar"
media types. Some of the ones that the Internet community has standardized
in RFC 2447 include:
EVENT PUBLISH (publish some arbitrary calendar data)
EVENT REQUEST (initial invitation, reschedule, delegate the invitation,
response to a counter-proposal)
EVENT REPLY (response to an invitation)
EVENT CANCEL (cancel the meeting or uninvite a single individual)
EVENT ADD (add a set of additional instances to an already scheduled event)
EVENT COUNTER (proposal an alternate time/place)
EVENT DECLINECOUNTER (decline a counter)
EVENT REFRESH (now, tell me the latest details for this meeting I am invited
to)
TODO PUBLISH (publish an arbitrary set of action items)
TODO REQUEST
TODO REPLY
TODO CANCEL
TODO ADD
TODO COUNTER
TODO DECLINE COUNTER
TODO REFRESH
JOURNAL PUBLISH
JOURNAL REQUEST
JOURNAL REPLY
JOURNAL CANCEL
JOURNAL ADD
JOURNAL REFRESH
A typical CUA action is to look into the MIME entity bucket for new
invitations.
All of these scheduling messages "sub-sub types" are represented in the same
single calendar media type. Tell me again, how you are going a scalable way
for a "calendar portal" site that has 100s of thousands of calendar users
wanting this info each day to service requests from CUAs for "new
invitations" or "invitation responses"? You can't expect the calendar
service to be able to parse ALL of the thousands of XML entities that are in
the MIME entity bucket to first find the calendar ones and then the "new
invitations" or "invitation responses".
If calendaring doesn't provide a real enough example, think about electronic
commerce and the millions of transactions a site may be handling a day. We
can't expect an EDI client to have to parse each of the XML entities in the
MIME bucket to find the "purchase orders".
- - Frank