RE: ACTION-472: New Mime-web-info draft

Just thinking about this more. How about two headers:

content-type: 
content-type-verified:

(I started with 'verified-content-type' but there is some belief that
'content-' headers stay associated with the MIME body and are rewritten
when the content is transformed but otherwise not, while other headers
are hop-to-hop or end-to-end but connected with the transmission.)


these two headers SHOULD be the same. If they're the same, the receiver
can rely on the content-type and must not sniff.  If there's only
content-type, then the sender hasn't verified the content-type and
receiver MAY sniff (but only within well-known and established rules.)

If they are different, then the content-type has been modified by
some unaware intermediary which has modified the content-type
without changing the "content-type-verified". In this case, the
receiver should accept the content-type as authoritative, since
the content-type transformation wasn't done unknowingly.

This might give a way of introducing out-out sniffing. Again,
this only works if the receivers which follow this protocol
are well-deployed in the field before any senders start sending
"content-type-verified".

Those write recievers believe (rightfully) that they have the last word, set the standard, get to do whatever they want, so that a "processing rule" may or may not actually be meaningful.  There are too many different kinds of receivers, not just browsers, but search engines CDNs, etc.

A server telling them what to do with a processing rule "sniffing: opt-out" ... well, it's bound to be ignored. 

However, if the sender is just telling the receiver MORE information, that has different semantics. Operationally, though, this is equivalent to the other proposal.

Larry
--
http://larry.masinter.net

Received on Tuesday, 1 February 2011 22:54:45 UTC