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

From: "Michael[tm] Smith" <[email-masked]>
Date: Tue, 7 Aug 2012 20:16:49 +0900

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 <[email-masked]>

Intended usage:
  Common

Restrictions on usage:
  No restrictions apply.

Author:
  Ian Hickson <[email-masked]>

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

---

From: Paul Libbrecht <[email-masked]>
Date: Tue, 7 Aug 2012 15:14:36 +0200

Michael,

HTML is very commonly exchanged over clipboards in widespread operating systems.
Could I suggest that you enrich the registrations of html and xhtml so that you include two fields with
- Windows Clipboard Flavor Name
- Macintosh Uniform Type Identifier
This way platforms, which mostly already define these types, would do so based on an open standard.

I can try to research the possible values if you want.
I am not sure about the multipart media type but I suspect this would also be welcome (maybe for html with attached objects?).

Paul

PS: I feel the Macintosh file type code is obsolete and unused.

Le 7 août 2012 à 13:16, Michael[tm] Smith a écrit :

> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Mark Baker <[email-masked]>
Date: Tue, 7 Aug 2012 10:00:25 -0400

Hi Mike,

I left the WG when HTML5 was deliberately backwards-incompatible,
making the update of text/html an error. AFAICT, this appears to have
since been addressed, at least judging by the text here;

http://www.w3.org/TR/html5-diff/#backwards-compatible

I recommend that the interoperability considerations section mention
this. Something as simple as;

"HTML5 is backwards compatible with all previous versions of HTML as
implemented. See
http://www.w3.org/TR/html5-diff/#backwards-compatible"

I included "as implemented" because I know the editors were always
keen to point out where multiple independent implementations strayed
from the specifications (and rightly so).

Mark.

---

From: "Michael[tm] Smith" <[email-masked]>
Date: Wed, 8 Aug 2012 02:14:21 +0900

> - Macintosh Uniform Type Identifier

Are those important just for HTML and XHTML, or are there other formats
which would benefit from having those defined as part of their
registrations?

If those would be useful or other formats, I'd suggest the guidelines for
media-type registrations be updated to suggest including them for all
registrations.

> I can try to research the possible values if you want.  I am not sure
> about the multipart media type but I suspect this would also be welcome
> (maybe for html with attached objects?).

The details for this registration are defined in the HTML5 spec, so I
suggest that if you want to make sure that data for those suggested fields
is included, it would be best to file a bug against the HTML5 spec itself:

  http://w3.org/brief/MjA2

---

From: "Michael[tm] Smith" <[email-masked]>
Date: Wed, 8 Aug 2012 02:28:41 +0900

> I left the WG when HTML5 was deliberately backwards-incompatible,

Not sure what in particular you thought was deliberately backwards-
incompatible, but OK.

> http://www.w3.org/TR/html5-diff/#backwards-compatible

I think that's just stating something that's always been true. The HTML5
spec has always intended to be backwards-compatible for existing browser
behavior. That has been the number one design principle of this entire
effort from day one:

  http://www.w3.org/TR/html-design-principles/#support-existing-content

> http://www.w3.org/TR/html5-diff/#backwards-compatible"

It's not intended to be "backwards compatible with all previous versions of
HTML". Judging whether anything is compatible with HTML4 has always been a
guessing-game exercise in creative interpretation. The HTML4 spec does not
actually state user-agent requirements in such as way that it's possible to
evaluate or test conformance to the HTML4 spec.

> from the specifications (and rightly so).

Outside of those differences, the HTML5 spec has always intended to be
compatible with existing behavior in browsers, which is generally not open
to being changed. So I'm not sure I'd actually call that "backwards"
compatibility. It's more like just compatibility with the Web.

Anyway, as a I pointed out to Paul, the details for this registration are
defined in the HTML5 spec itself. So if you want your proposed wording
added, I suggest you raise a bug against the HTML5 spec:

  http://w3.org/brief/MjA2

---

From: Ned Freed <[email-masked]>
Date: Tue, 07 Aug 2012 15:25:03 -0700 (PDT)

> which would benefit from having those defined as part of their

They probably are.

> media-type registrations be updated to suggest including them for all

I'm afraid it is a little late for that. The media types registration
were just updated. Had this been proposed during the updating process (which
took over a years), I can pretty much guarantee it would have been included,
but the document is now final and it's too late.

By way of reference, the last update happened in 2005.

My suggestion would be to put these in the additional information section.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 07 Aug 2012 23:06:25 -0700 (PDT)

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

---

From: "Michael[tm] Smith" <[email-masked]>
Date: Wed, 8 Aug 2012 21:53:35 +0900

> thought it was a good idea to point it out.

Actually I wasn't aware of it :-) But that explains a few things.

So to be clear: Is the correct procedure now to use the
http://www.iana.org/cgi-bin/mediatypes.pl form?

  --Mike

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Aug 2012 13:47:25 -0700 (PDT)

> http://www.iana.org/cgi-bin/mediatypes.pl form?

Either that or send the registration to IANA by email. [email-masked], I
believe.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Aug 2012 14:07:36 +0200

> Not sure what in particular you thought was deliberately backwards-

Some things that are valid HTML4 aren't conforming (valid) in HTML5 anymore.

Best regards, Julian

---

From: "Michael[tm] Smith" <[email-masked]>
Date: Thu, 9 Aug 2012 21:27:13 +0900

> Some things that are valid HTML4 aren't conforming (valid) in HTML5 anymore.

I wouldn't call that backwards-incompatible, because it only relates to
validation. I take backwards-compatibility to mean that we're not breaking
browser behavior for any existing content on the Web. Any elements or
attributes that had browser processing/rendering behavior associated with
them prior to HTML5 have that same behavior in HTML5. Document conformance
and validity are a separate thing, and making that always match what HTML4
is a non-goal.

  --Mike

---

From: Paul Libbrecht <[email-masked]>
Date: Thu, 9 Aug 2012 16:44:28 +0200

Michael, Ned,

>> which would benefit from having those defined as part of their

Thus far, I have been monitoring the list and suggested this when it appeared to make sense. Sometimes, media-types seem to be too specific to be entering a clipboard.

HTML and its cousins are clearly good candidates to live in the clipboard!

> but the document is now final and it's too late.

Ned, is there another list I should monitor to see discussion of another round of update of this recommendation?
(as indicated elsewhere, I'd also suggest that the Macintosh 4-letter type be dropped)

> My suggestion would be to put these in the additional information section.

Thanks, I have formulated this on the bug I just opened:
	https://www.w3.org/Bugs/Public/show_bug.cgi?id=18508

Paul

---

From: Ned Freed <[email-masked]>
Date: Thu, 09 Aug 2012 14:58:30 -0700 (PDT)

> round of update of this recommendation?

Aside from monitoring the main IETF list for new drafts pertaining to media
types, not really. As I said, the latest update is done and about to be
published. It will almost certainly be a year - and quite possibly longer -
before another update is contemplated. If and when that happens there is really
no way to predict when or where the discussion occur.

> (as indicated elsewhere, I'd also suggest that the Macintosh 4-letter type be

As a practical matter, that's really not possible since existing registrations
include it and so it has to be described. That said, it was relegated to an
much less prominent role in the revision.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Aug 2012 12:23:29 +0200

> and validity are a separate thing, and making that always match what HTML4

Understood.

But media type updates are not supposed to make existing content 
invalid; thus the updated text/html registration needs to state that, 
for instance, HTML4 strict can continue to be labelled text/html.

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Fri, 10 Aug 2012 17:17:50 +0000 (UTC)

> for instance, HTML4 strict can continue to be labelled text/html.

This is obviously not true since the current text/html registration 
doesn't say HTML2 is valid, instead referencing HTML4 and XHTML1.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Aug 2012 09:56:49 +0200

> doesn't say HTML2 is valid, instead referencing HTML4 and XHTML1.

<http://tools.ietf.org/html/rfc4288#section-9>:

    Changes should be requested only when there are serious omissions or
    errors in the published specification.  When review is required, a
    change request may be denied if it renders entities that were valid
    under the previous definition invalid under the new definition.

So it's indeed not a hard requirement.

RFC 2854 indeed isn't very clear about the past versions, but that 
doesn't mean we shouldn't do better this time.

The question here is: can I continue to label a (valid) HTML4 document 
which is *not* a (conforming) HTML5 document as text/html? If the answer 
is yes (and I'm pretty sure it is), the media type registration should 
mention this.

(I also note that if we don't update RFC 2854 -- which would be my 
preference -- then we should to obsolete it)

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 22 Aug 2012 17:56:44 +0000 (UTC)

> is yes (and I'm pretty sure it is), the media type registration should 

It does mention this. "Labeling a resource with the text/html type 
asserts that the resource is an HTML document using the HTML syntax."

There's no need to specify specific versions.