Re: Feedback on Internet Media Types and the Web

Larry Masinter wrote:
>
> > But that's exactly the sort
> > of situation the IANA registry is meant to avoid, in the standards
> > tree anyway. 
> 
> When vendors can and do deploy software which uses non-registered
> values in situations where registration is required, the registration
> process does not accomplish this intention: the situation it is
> meant to avoid is not avoided.
> 

The situation I was referring to, is the one where one type is
associated with multiple processing models.  Another situation is where
a type makes no mention of, or incorrectly describes, security
considerations.  The standards tree does avoid these problems, and I
consider these successes, not failures.  I'd rather preserve the
successful aspects of the registry, rather than declaring the whole
concept a failure, because I have a high degree of confidence in media
types appearing in the standards tree not exhibiting these problems.  I
have no such confidence in strings which are not media types (the term
"media type" is defined as what's been approved and appears in the
registry).

>
> Are there any other situations outside the web and browser vendors
> where this happens, or is this unique to the web? 
>

Not sure what you're asking, or what it has to do with vendors of
browsers, servers or intermediaries.

> 
> >  I believe the standards tree serves a valuable purpose,
> 
> It is intended to serve a valuable purpose, but it apparently
> does not serve that purpose.
> 

It does, for those who've been approved, and for those who want the
imprimatur of expert peer review before allowing a type to traverse a
firewall, rather than having to take the creators' word for it.  In my
opinion, what we have are process issues, not conceptual issues -- how
do we improve the registry, as opposed to what do we replace it with.

>
> >  and
> > that it would be a bad thing to let anarchy reign by stating that it
> > doesn't matter whether the rules for media types are followed,
> > g'head and deploy whatever, and let popular consent override
> > technical concerns.
> 
> Anarchy does reign.  There is no harm, foul, or back-pressure
> against deploying unregistered values.
>

Anarchy is what happens if there are no rules or process.  The harm in
deploying unregistered types, is less scalability.  The set of types
that's uniformly understood by search engines, Web accelerators,
caches, firewalls, servers etc. is limited (and, mostly, registered).
Staying within that set brings benefits which do not accrue otherwise.
Many firewalls block traffic of known media types -- Java, Javascript,
PDF etc., these firewalls don't allow arbitrary types to pass, and
sysadmins shouldn't need to use a search engine to determine whether or
not to allow a type (easier to block than to spend all day researching).

>
> There is at least some amount of perceived benefit (or at least
> cost-reduction) in deploying unregistered values: perhaps the rules
> are unnecessarily stringent, the registration requires additional
> work which has not been done, or perhaps just advanced notice to
> competitors of intended new values or applications. 
> 

Or, just an outright lack of knowledge that the registry exists, as I
found over the course of a year spent agitating folks on this issue.
Which is why I like the section about updating AWWW, surely such action
would help raise awareness.  I'd like to see what, if any, effect this
would have on the developer community, before considering anything too
radical in the way of change.  Head down, follow through...

> 
> I don't think it's useful to try to find who to "blame". Individuals
> and organizations behave in ways that ultimately optimize their
> value within the situation established. Adding barriers-to-entry
> into a registry, where there is no mechanism of enforcement and
> even slight benefit to avoiding the barriers will yield a situation
> where unregistered values are widely used. 
> 

OK.  "What we have here, is failure to communicate."  Awareness of not
only the registry, but its importance, has lagged behind the times -- I
believe that the TAG needs to do a better job "riding herd" on the
various activities in future, to ensure that media types are being
created and registered where appropriate.  The TAG has dropped the ball
on this in the past, which I say not to assign blame, but to point out
that an opportunity was missed for w3c activities to set an example of
proper architecture.  This can't be undone, but since developers copy
what's been done in the past, the situation can be expected to improve
moving forwards, with improved vigilance.  Not quickly, but eventually.

>
> > I go to the registry to find media types that have been vetted by
> > experts and known to meet some basic requirements.  If the registry
> > becomes a list of everything anyone wants to do, whether it meets
> > those requirements or not, well, I'd consider that a failure of the
> > registry.
> 
> It seems like in most situations, denying entry into the registry
> is not a strong deterrent. Perhaps it was at the time the registries
> were established -- a world without wikipedia, google search, wikis
> or the web, where IANA controlled a rare resource: a reliable method
> of publication of information. Back then, denying entry into an
> IANA registry meant something. Now, as we see, people just route
> around the blockage, go to the Wikipedia article on "URL schemes"
> or a search engine to find some spec or another for the token they're
> looking for.
> 

If they know the token, sure.  As a developer, I often visit the IANA
registry to search for prior art.  Even today, I can't formulate a
search for "all known XML media types," which isn't even what I'm
looking for -- what I want is a list of all known XML types that have
been subjected to expert review, so I don't have to judge for myself
whether they have interoperability or security concerns the creators
don't want me to know about (another reason to forego registration).
This also holds true when I have my sysadmin hat on, configuring a
firewall -- in which case I know the token, but need a source for this
information that I can trust.  Which isn't the creators' websites.

>
> > The rules are quite clear -- pending approval, prefix with x. i.e.
> > image/x.svg+xml or application/x.rss+xml.  Refusing to follow the
> > appropriate syntax *and* ignoring what media types are supposed to
> > do, shouldn't be rewarded with registration
> 
> registration carries almost no value in today's world, so
> withholding it isn't effective.
> 

I disagree.  If I go to the trouble of creating a new type, I'd rather
not leave it to chance whether or not anyone notices it.  Whereas if I
register, it's on display for everyone to see, and if it's in the
standards tree it's more likely to be re-used (or, simply allowed to
traverse firewalls) since nobody considering re-using it needs to take
me at my word on interoperability or security concerns.  So, I see a
tremendous value around the trust relationship IANA establishes, from
the producer, adopter and consumer perspectives.

>
> > -- the IANA registry isn't
> > perfect, but destroying its credibility such that nobody has any
> > faith in any media types, sounds counterproductive to me, and would
> > be a much larger problem than the handful of strings out there
> > which *look* like standards-tree media types, but aren't.
> 
> I think we need some other way of addressing the problem.
> 

Not sure what you mean.

>
> I don't have a proposal I want to make. Here's a draconian,
> non-workable example, though: what if the W3C patent policy only
> applied to implementations that followed the W3Cspecifications, and
> W3C specifications required registration of values used in
> implementations? I know this isn't really workable, but perhaps there
> is some way of getting vendors to avoid unregistered values by
> associating a cost with that use?
> 

I believe there's an inherent cost anyway, and that awareness of same
needs to be raised, or at least tried, before trying anything more
stringent.  There's really no way to disallow unregistered types, and
plenty of reasons to keep allowing them, so they'll always be with us.
I've thought long and hard about this, but can't find a solution that
doesn't wind up being less desirable than the current situation.  All
we can do is improve that situation, by changing the registry and the
process to be more flexible and user-friendly, and increased advocacy.

>
> I'm going to have to boil all of this down into wording to fit
> into the mime-web-info document.... any help with that would be
> really appreciated. Again, the goal is to (a) describe the situation
> and history (b) explain the problems (hopefully in neutral wording 
> without getting into 'blame'), and (c) identify the nature of the
> possible solutions and where in the process/specifications/documents
> those solutions would go.
> 

There definitely needs to be a section on what it would take to
formalize extension types, i.e. +json and any others folks are already
using in the wild.  There's a huge logjam around +json, where if it
were even *possible* to register such types, we'd likely see much more
registration/standardization.  The fact that +json is a nonstarter,
contributes greatly to souring the developer community on the entire
notion of a registry.  The problem isn't the concept, though, it's the
process.  Fix the process, save the concept.  Allow +json, and so many
new media types may appear that this action alone contributes
substantially to raising awareness that IANA is something besides a
"registry of no" that's best avoided.

Going beyond the production of this document, I'd say that enabling
+json is probably the best place to start.  It won't be quick, nor will
it be easy given the number of specs which need changing, but it will
serve to bring the registry into the modern era instead of coming
across as an unneccessary relic of the 90's, reducing the ill-will of
developers who've seen their efforts thwarted and quite possibly turning
them into advocates.

-Eric

Received on Wednesday, 10 November 2010 04:39:46 UTC