Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?

[Ned Freed <[e-mail]>]

> ----- Original Message -----
> From: "Dave CROCKER" <[e-mail]>
> To: "Apps Discuss" <[e-mail]>
> Sent: Thursday, November 10, 2011 7:59 AM
> > Folks,
> >
> > On 11/10/2011 2:02 PM, Barry Leiba wrote:
> > >> But the fact is that we have a major/minor type system. We can as well make
> > >> reasonable use of it.
> > >
> > > As I said in the other thread (on font/*), we already have the concept
> > > of saying "This is text," "This is an image," and "This is audio," and
> > > I see only negative points in insisting that everything other than the
> > > few TLMTs that we're already defined have to be "application".  We
> > > should do some filtering and apply some judgment, of course, but
> > > making everything the equivalent to "application/image-jpeg" is silly
> > > and non-useful.
> >
> > That states a basic direction/goal: To have a lower hurdle than perhaps was
> > there before.
> >
> > Does it have any basic downsides?
> >
> > My sense from the latest round of postings, including Ned's, is that there is
> no
> > current reason to impose a high hurdle on TLCTs.
> >
> >       Consensus check
> >       ===============
> >
> >       Is there anyone out there who believes that it is extremely expensive or
> > dangerous to introduce new, top-level Content-Type and that, therefore, the
> > barrier to new TLCTs should be (kept) high?

> Yes.  Based on FUD rather than concrete information, but what will all the
> deployed software do when face with a new top-level Content-Type?

I'm pretty familiar with a lot of different software that handles media types,
and in every case I know of the answer is "it already supports it".

This is a consequence of the fact that it's easiest to treat leaf media type
names as simple case-insensitive strings. Anything else is more work for no
good purpose. And one thing you can usually count on implementors to do is not
go to a lot of extra effort only to make their software harder to use and more
fragile.

> And how long
> will it take for the makers of commercial software to incorporate this in their
> products (1-2years) and how long will it take for that software to be widely
> deployed(3-5 years)?

I have yet to see any evidence that any software currently has problems of this
sort.

> I just received an (antisocial) e-mail with .gif's attached, so I edited the
> Content-Type to be font/various things, and my MUA took no notice, just
> processed them as .gif.

A lot of agents, when presented with a type they don't know, will either
use the file extension, sniff the data, or both. 

Now, you may think this handling is a bad idea (or not), but it has almost
nothing to do with top-level type usage. In fact the same thing would almost
certainly have happened had you changed the media type to image/foo or
application/foo. 

The only thing you have demonstrated in regards to unknown top-level types is
that your application doesn't choke on them.

> I modified the Content-Description in the same way, same result.

I completely fail to see why you would expect any other result. It's a textual
description, not supposed to be machine actionable, you know.

> Only when I modified the filename (eg to .ttf) did the MUA take any notice and
> complain that the attachment was not a font, pdf etc.

In other words, you changed the file extension to one that your application
knows is associated with a font of some kind. So it tried to process it
as such and got an error.

And again, to the extent this has anything to do with top-level types, you have
just shown your application to be capable of handling previously unknown ones
without falling over. And that's all you have shown.

But if you want to actually perform a more complete test, you should have tried
to add a font/* entry to your application's media type tables and then tested
with content having that label. I've done that lots of times and previously
unknown top-level types have never been a problem.

> I think we need to know this for commonly deployed platforms before we can say
> it is not dangerous.

If you regard the behavior you describe as dangerous, well, we appear to be
working from very different definitions of the word "dangerous".

				Ned