I think that using specialized media types - one for every XML app - can be
a potential scalability problem. Even if the media type registration is
impressively fast today (one day!), I anyway doubt that it's appropriate to
have a central authoritive for this purpose.
One particular problem is the naming of media types in the Vendor tree:
text/vnd.*
You can put whatever you like after 'vnd', and that's what people do.
I wonder why media types can't use similar naming rules as, for example,
java classes (domain names) or XML names (URIs). Wouldn't it be possible to,
in some way, join the MIME Media type tree with the domain names. For
example,
text/xml.org.w3.html, would be XHTML
and
text/xml.com.anyCo.myXmlApplication, would be someone's XML application.
but
text/html, would still be HTML
That way, the browser can, even if it doesn't recognize the type, at least
see that it's an XML document (and perhaps display it). It also means that I
can create my own media types without having to contact a central naming
authority (except for getting the domain name). I can also further sub-type
my own media type.
Perhaps some sort of new URN should be used instead, I don't know. Anything
would be better than "vnd.whatever.."-names.
PS
-----Original Message-----
From: owner-ietf-xml-mime(_at_)imc(_dot_)org
[mailto:owner-ietf-xml-mime(_at_)imc(_dot_)org]On
Behalf Of Ned Freed
Sent: Wednesday, April 07, 1999 3:11 PM
To: Larry Masinter
Cc: Earthlink; ietf-xml-mime(_at_)imc(_dot_)org
Subject: RE: Starting the ietf-xml-mime mailing list
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