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.
Agreed.
My quick and dirty way of thinking of this is that the media type/subtype
should to be sufficient to get you the right application, but the parameters
then can tell that application what to do, or when to do it, or various other
sorts of things that for whatever reason are best not stored in or derived from
the actual content.
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. 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?
Of course the general case of this problem may in fact be intractable, even
with full access to message content. (Define "boss". Figure out how to relate
the origin of a given event invitation to this definition of "boss". Etc.)
However, in the general problem space surrounding these sorts of applications,
I see value in using parameters. For example, I may wish to have certain
sorts of calendar operations handled silently and automatically, whereas
others need to be done manually.
In short, I agree with Frank that parameters have their uses in this context.
Ned