I'm saying you definitely have a problem: you have a complex space
of possible objects:
"all possible calendaring events, with indication as to the applicable
users, the nature of the event, whether it's a request, a response,
the dates involved, urgent"
You need to query this space, find those that match a particular
set of criteria, and then retrieve the objects that match your criteria.
Neither adding parameters to text/calendar nor inventing new
MIME subtypes for text/calendar-request text/calendar-response etc.
will help implement the query capabilities that you need.
Since it doesn't work, stop trying. You need some other kind of query
protocol than keying off content-type.
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.
No, I think this is a poor characterization. The CUA needs to be able
to search the MIME entity bucket for particular calendar events that
match a particular query, "all repeating events that do not occur
on Thursday". Trying to cram this into the type space is just poor
engineering.
Yes, it needs to search the MIME entity bucket. No, the search is not
characterized by "type".
All of these scheduling messages "sub-sub types" are represented in the same
single calendar media type.
You may want to characterize them as "sub-sub types", but it is a misuse
of the type space.
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".
Someone has to parse them. Certainly if a search engine can parse web
pages to find the words and their lexical equivalences, an event search
engine can parse the XML documents and index them in the multiple ways
that searching the calendar-event database needs to be searched.
If calendaring doesn't provide a real enough example,
Yes, the example is real, and shows that this problem can't be solved
by overloading the MIME type space.
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".
Purchase orders that are applicable to the particular division, purchase
orders that haven't already been processed, purchase orders that are
assigned to a particular account rep, etc. These are all database search
problems, not type-indexing problems.
Larry