Specialised media types (was RE: Starting the ietf-xml-mime mailing list)

["Peter Stark" <stark@xxxxxxxxxxx>]

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@xxxxxxx [mailto:owner-ietf-xml-mime@xxxxxxx]On
> Behalf Of Ned Freed
> Sent: Wednesday, April 07, 1999 3:11 PM
> To: Larry Masinter
> Cc: Earthlink; ietf-xml-mime@xxxxxxx
> 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
>
>