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

["Martin J. Dürst" <[e-mail]>]

Hello Dave,

On 2011/11/10 11:54, Dave CROCKER wrote:
> Folks,
>
> The font thread has re-raised the issue of registering a Top-Level
> Content-Type (TLCT). I haven't seen clear statements or documents of a
> theory or rationale that would guide accepting or rejecting a request
> for a TLCT, and I think we should (finally) remedy this deficiency.

If somebody has some free time to work on this, why not. But both in the 
IETF and elsewhere, my experience is that it's difficult to create a 
general theory with very few examples. And this is a case with extremely 
few examples. So I'd rather spend my time on the concrete case. This 
would hopefully result in some mime types actually being registered.

> In an earlier note I cited a recollection of resistance to new TLCTs.
> But I don't remember the reasons, though I seem to recall both substance
> and vigor to the reasons.

That has been reported elsewhere, see e.g.
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1069.html

It would be good if we found an archive of this discussion, just so that 
we could understand what went on then. But if we can't find that 
anymore, then we shouldn't care too much. If we forgot why there was 
resistance, maybe it wasn't that important.

> We should try to resurrect or re-create a simple, pragmatic set of
> guidelines, and document them, so we don't have to go through the kind
> of vague exchanges happening now, with respect to arguing whether a new
> TLCT is appropriate.
>
> The purpose of this thread is to press for a brief document that
> resolves this kind of debate and that can be used going forward in
> designing the "structure" of new registration groups. This ought to be
> in terms of real pragmatics, rather than aesthetics or personal preference.

I'm going to discuss this with you here because I'm interested in the 
example at hand, not because I want to create a general theory.

> I can think of only two pragmatic issues in registering names like this:
>
> 1. Administrative convenience. A hierarchy permits administrative
> grouping and possibly the convenience of delegating subsets of
> registration. Obviously the DNS is the prime example. At very large
> scale, this is essential. At small scale, extra structure can be a hassle.
>
> I'm not seeing convenience as an issue for Content-Type, but perhaps
> others see the issue differently. That is, my sense is that the entire
> data base of content-types is small enough to a) remain centralized, and
> b) not otherwise needing to benefit from sub-setting.
>
> This calls to question why there are /any/ sub-types, of course, but I'd
> rather cast the issue in terms of going forward, rather than of history.

I agree that delegating subsets along major types doesn't make sense. 
But there's another administrative reason for having major/minor types: 
It's hopefully easier to find a type you're looking for, or check that a 
type hasn't been registered. As a clear example, for image formats, I 
know that http://www.iana.org/assignments/media-types/image/index.html 
is where I have to check.


> 2. Code dispatching. Different content-types invoke different software
> segments. Parameters are input to the code but do invoke different
> "programs".
>
> I am not seeing how a TLCT vs. sub-type distinction affects this issue.
> That is, it seems to me that
>
> C-T: major/minor
>
> has equal software utility as
>
> C-T:application/major-minor
>
> Any useful difference seems to be to fall under #1, above, rather than
> under a software behavior distinction. What am I missing?

I think that fonts are dispatched quite differently e.g. from 
application data. For application data, the general solution is to call 
up the respective application (or ask the user to select or confirm 
one). For font data, there are of course applications that work on the 
data directly (e.g. editors). But the main usage is that they are saved 
(or installed) separately and used as auxiliary documents.


> The 'model' document talks about a benefit of grouping sub-types, but I
> do not understand what the software benefit is, in terms of MIME
> Content-type. That is, the benefit seems to be a local benefit within
> the model world, rather than more generally within the MIME world.
> Again, what am I missing?

You may not be missing too much. It's easy to imagine a world with a 
flat type system, or with a type system that didn't have image/, audio/, 
and video/.

But the fact is that we have a major/minor type system. We can as well 
make reasonable use of it.


> To take the 'font' discussion as an immediate, real-world exemplar, I
> think the above says that a logical hierarchy should have the
> representation engine be superior to the typeface or font specification,
> since it affects software dispatch.

I'm not sure I understand this point. Can you elaborate. What do you 
mean by "representation engine"?


> Also, I don't see what the driving need for a TLCT is for font (or
> face...) It's aesthetically appealing, but I don't see the technical or
> administrative benefit. Hence, here's one last: what am I missing?

Glad you agree that it's aesthetically appealing. And please remember 
that people involved with fonts care quite a lot about aestetics.

As for the technical/administrative benefits, things such as easy 
searchability and easier negotiation (e.g. Accept: font/*) and despatch 
have already been mentioned.

These benefits are not necessarily tremendous, but the same applies to 
image/, video/, and audio/.

Regards,   Martin.