Larry Masinter wrote:
[Frank wrote]
In addition, though, we also want to get at subtypes of objects. Or in the
case of MIME type/subtypes, this would be the "sub-sub type". For example,
for a calendar object (text/calendar) we want to pull to the client just the
"event invitations". This would be the "sub sub type" of type=text,
subtype=calendar.
This is a good example of a problem that specialized media types won't solve.
But it sure cuts down the class of data to be further processed. Instead
of searching through the entire mailbox/the entire server, just search
in the text/calendar resources.
You might also want to scan your email for "event invitations from my boss",
and you can't solve that problem with specialized MIME media types.
You can't solve that problem in its entirety with specialised MIME media
types, but you can go a good part of the way and have a better start
than, for example, sending all calendar events as text/plain.
text/calendar;category=work;recurring=monthly (to take a suggestive but
doubtles invalid example) would help even more - the parameters could be
used to cut down on the search spoace even further.
So the
question is: are there any realistic cases where having a "text/calendar"
distinction in the email header actually helps substantially in deciding
which email bodies to retrieve?
Yes; especially in the case of IMAP where the initial selection of bodis
is done on the server and likely ones are sent to the client for the
calendar program to further process.
--
Chris