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

["t.petch" <[e-mail]>]

Dave

In this thread, there have been a number of references to how easy it is, or
not, to implement which, for me, should always be secondary to how easy it is to
use.

There is a use which is perhaps being missed which, for me, is the most
important one, and that is in keeping spam out of the system.  Being able to say
.exe goes into the bin unread is very important.  I am out of touch with current
spam filtering but believe that Media Type is a significant part of it.
(Personally, I would like ietf lists to be restricted to text/plain and while no
list moderators go that far, I have seen posts, in the past, from some
explaining what they will not allow on WG lists).

In this context, as has been said already, perhaps for very different reasons,
html should have been top-level, but we are too late for that.

Tom Petch

----- Original Message -----
From: "Dave CROCKER" <[e-mail]>
To: "Apps Discuss" <[e-mail]>
Sent: Thursday, November 10, 2011 3:54 AM

> 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.
>
> 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.
>
> 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 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.
>
>     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?
>
> 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?
>
> 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.
>
> 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?
>
> d/
> --
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net