Re: [ietf-types] Update to text/html registration

Ned Freed <ned.freed@mrochek.com> Wed, 08 August 2012 06:20 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4473611E813F for <ietf-types@ietfa.amsl.com>; Tue, 7 Aug 2012 23:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level:
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG9lE5CQRbmO for <ietf-types@ietfa.amsl.com>; Tue, 7 Aug 2012 23:19:59 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1DE11E8138 for <ietf-types@ietf.org>; Tue, 7 Aug 2012 23:19:59 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OISEPWW4XS0066VA@mauve.mrochek.com> for ietf-types@ietf.org; Tue, 7 Aug 2012 23:14:55 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Tue, 7 Aug 2012 23:14:52 -0700 (PDT)
Message-id: <01OISEPVDL760006TF@mauve.mrochek.com>
Date: Tue, 07 Aug 2012 23:06:25 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 07 Aug 2012 20:16:49 +0900" <20120807111647.GB67292@sideshowbarker>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20120807111647.GB67292@sideshowbarker>
To: "Michael[tm] Smith" <mike@w3.org>
Cc: ietf-types@ietf.org
Subject: Re: [ietf-types] Update to text/html registration
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 06:20:00 -0000

I should also point out that ietf-types is a review list only, and note  that
posting stuff here does NOT make it a formal update request. Under the newly
adopted rules, that has to be done by submitting the update request to IANA.

You may already be aware of this, but I given the wording of the messages I
thought it was a good idea to point it out.

				Ned

> Please update the registration for the text/html media type to reference
> the HTML5 specification instead of RFC 2854.

>   http://www.w3.org/TR/html5/iana.html#text-html

> ---------------------------------------------------------------------------
> Type name:
>   text

> Subtype name:
>   html

> Required parameters:
>   No required parameters

> Optional parameters:
>   charset
>     The charset parameter may be provided to definitively specify the
>     document's character encoding, overriding any character encoding
>     declarations in the document. The parameter's value must be the name of
>     the character encoding used to serialize the file, must be a valid
>     character encoding name, and must be an ASCII case-insensitive match
>     for the preferred MIME name for that encoding. [IANACHARSET]

> Encoding considerations:
>   8bit (see the section on character encoding declarations)

> Security considerations:
>   Entire novels have been written about the security considerations that
>   apply to HTML documents. Many are listed in this document, to which the
>   reader is referred for more details. Some general concerns bear
>   mentioning here, however:

>   HTML is scripted language, and has a large number of APIs (some of which
>   are described in this document). Script can expose the user to potential
>   risks of information leakage, credential leakage, cross-site scripting
>   attacks, cross-site request forgeries, and a host of other problems.
>   While the designs in this specification are intended to be safe if
>   implemented correctly, a full implementation is a massive undertaking
>   and, as with any software, user agents are likely to have security bugs.

>   Even without scripting, there are specific features in HTML which, for
>   historical reasons, are required for broad compatibility with legacy
>   content but that expose the user to unfortunate security problems. In
>   particular, the img element can be used in conjunction with some other
>   features as a way to effect a port scan from the user's location on the
>   Internet. This can expose local network topologies that the attacker
>   would otherwise not be able to determine.

>   HTML relies on a compartmentalization scheme sometimes known as the
>   same-origin policy. An origin in most cases consists of all the pages
>   served from the same host, on the same port, using the same protocol.

>   It is critical, therefore, to ensure that any untrusted content that
>   forms part of a site be hosted on a different origin than any sensitive
>   content on that site. Untrusted content can easily spoof any other page
>   on the same origin, read data from that origin, cause scripts in that
>   origin to execute, submit forms to and from that origin even if they are
>   protected from cross-site request forgery attacks by unique tokens, and
>   make use of any third-party resources exposed to or rights granted to
>   that origin.

> Interoperability considerations:
>   Rules for processing both conforming and non-conforming content are
>   defined in the HTML5 specification.

> Published specification:
>   This HTML5 specification is the relevant specification. Labeling a
>   resource with the text/html type asserts that the resource is an HTML
>   document using the HTML syntax.

> Applications that use this media type:
>   Web browsers, tools for processing Web content, HTML authoring tools,
>   search engines, validators.

> Additional information:
>   Magic number(s):
>     No sequence of bytes can uniquely identify an HTML document. More
>     information on detecting HTML documents is available in the Media Type
>     Sniffing specification.

>     File extension(s):
>       "html" and "htm" are commonly, but certainly not exclusively, used as
>       the extension for HTML documents.

>     Macintosh file type code(s):
>       TEXT

> Person & email address to contact for further information:
>    Michael[tm] Smith <mike@w3.org>

> Intended usage:
>   Common

> Restrictions on usage:
>   No restrictions apply.

> Author:
>   Ian Hickson <ian@hixie.ch>

> Change controller:
>   W3C

> Fragment identifiers used with text/html resources either refer to the
> indicated part of the document or provide state information for in-page
> scripts.
> ---------------------------------------------------------------------------

> --
> Michael[tm] Smith http://people.w3.org/mike
> _______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types