Web / Internet Tension
Indicating Security Context
Indicating the security context of a connection in the URL -- usually, using the URL scheme -- is therefore critical to the Web stack: Whether or not a network attacker controls the content of a security context is encoded in the distinction between https and http, and (to first order), insecure scripting contexts are isolated from insecure contexts.
New mechanisms are also being built with the requirement to distinguish between secure and insecure contexts based on their URI built in (e.g., CORS ).
In the Internet architecture, protocols are encouraged NOT to reflect security properties by registering a separate URL scheme or using a separate TCP/UDP port. It is widely believed that protocols should upgrade their security properties without changing them, based upon the requirements of the application.
Increasingly, Web applications are needing to perform discovery to find nearby resources. E.g., CORE  is chartered to do this, and examining emerging Web architecture for discovery such as well-known URIs  and the hostmeta format  (packaged as LRRD ).
MIME and HTTP
HTTP is a "MIME-like" protocol, but not actually MIME. While issues in HTTP/MIME gateways haven't often been seen in deployment, there have been architectural issues brought about by the differences.
For example, HTTP uses the media type system from MIME to identify message intent. It also allows a message to be encoded using a content-coding (end to end) or transfer-coding (hop-by-hop). However, some Web formats want to be able to unambiguously identify whether something is compressed using a filename extension (e.g., svg vs. svgz).
See also Larry's blog.