Re: the problem of unregistered MIME types, URI schemes, etc.

Larry Masinter wrote:
>
> On the "happiana" mailing list, I was trying to make the claim that
> the widespread use of unregistered MIME types was a security and
> reliability problem in the web... that whenever there's a potential
> for a disagreement about what a communication term means  -- where
> the sender intends one thing and the receiver understands another,
> and they're both (more or less conforming) --  that this is a
> priority for us to fix.
> 
> (see the thread starting
> http://www.ietf.org/mail-archive/web/happiana/current/msg00016.html
> for example)
>

Tough room...

> 
> Some of the pushback has been that this is not a reliability problem,
> that the fix for the problem is not in the IANA registration process
> or anything maintainable by the IETF, and a few other things ....
> 

The collision problem is inherent in any protocol which splits resource
from representation, so if it is a security and reliability problem, the
solution is FTP.  No registry prevents me from saving a JPEG as .gif
and serving it as image/png -- calling an incompatible processor is
only an error, though, which doesn't become a security issue until the
client attempts to divine sender intent through sniffing (especially if
that intent was to sneak an infected JPEG past an antivirus gateway).

So even the clearest, simplest and easiest-to-maintain registry process
can't stop folks from doing whatever the heck they want to do -- like
cause major corporations to stop using standards-tree syntax for media
types they have no intention of registering, regardless of the nature
of the process, or even if they're already registered.  Unless there's
some way to compel compliance.

>
> The conclusion I reach is that the problem of getting existing types
> registered isn't going to happen in IETF, that it is a "web
> reliability" problem...
> 

I'm satisfied with the proposal to allow third-party registration, and
the proposal for +suffix registration should help bring the registry in
line with reality.  Is it realistic to register everything seen in the
wild, without abandoning the standards tree concept, though?  Why would
that be more desirable than maintaining some minimal architectural
stewardship through a reserved syntax?

>
> Having widespread use of unregistered types, URI schemes, etc. labels
> is harmful, and that if the "fix" is something beyond what IETF and
> IANA provide, that perhaps W3C could provide some resources to help.
> 

I still support updating WebArch to include this discussion as
important to the long-term scalability of the Web, but not calling it
harmful.  I'm using application/x.xbel+xml, which can't be registered,
nor should it be as it's experimental.  I don't see what harm it does.

I also see the request for hard data as unreasonable -- I've read the
rules, so I know I'd be wasting my time trying to register application/
xbel+xml.  So there's no failed effort to point to, IOW unattempted
registrations can't be quantified, but they're definitely out there.
I'm not a standards body, so I can't register that as a third party,
but perhaps w3c could under the proposed rules?  But what's the
motivation to do this on behalf of the one developer who's expressed an
interest in it?

OTOH, if it catches on and proliferates without being registered,
aren't we better off having it registered by *somebody*?  Sure, if it
conforms to the standards-tree rules; but if it doesn't, what does it
break to leave it out?

>
> Do you agree or disagree with this analysis or direction?
> I think part of the issue is whether new URI scheme registrations
> should be encouraged - even if you don't like inventing new URI
> schemes....
> 

Too orthogonal.  Media types have a standards tree, which allows some
architectural stewardship, whereas URI schemes have no reserved syntax.
So a URI-scheme registry should simply catalog what's out there in the
wild, which is the point of anything-goes vnd. and prs. trees.  Unless
you think that should be the purpose of the registry as a whole, in
which case you're proposing to eliminate standards-tree restrictions,
and deprecate the x. prefix.

-Eric

Received on Tuesday, 9 August 2011 04:52:07 UTC