Subject: Re: [ietf-types] Update to text/html registration
From: Ian Hickson <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: [email-masked]
Date: Wed, 22 Aug 2012 17:56:44 +0000 (UTC)
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On Wed, 22 Aug 2012, Julian Reschke wrote:
> 
> 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.

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.

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

Date: Wed, 22 Aug 2012 10:14:07 +0200
From: Julian Reschke <[email-masked]>
To: "Michael[tm] Smith" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration for text/event-stream

On 2012-08-07 13:45, Michael[tm] Smith wrote:
> This is a request to register the text/event-stream media type by reference
> to the Server-Sent Events specification:
>
>    http://www.w3.org/TR/eventsource/#text-event-stream
>
> ---------------------------------------------------------------------------
> Type name:
>    text
>
> Subtype name:
>    event-stream
>
> Required parameters:
>    No parameters
>
> Optional parameters:
>    charset
>      The charset parameter may be provided. The parameter's value must be
>      "utf-8". This parameter serves no purpose; it is only allowed for
>      compatibility with legacy servers.
> ...

I note that this one and text/cache-manifest are different with respect 
to charset; is there a good reason for this?

Best regards, Julian

Date: Wed, 22 Aug 2012 09:56:49 +0200
From: Julian Reschke <[email-masked]>
To: Ian Hickson <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

On 2012-08-10 19:17, Ian Hickson wrote:
> On Fri, 10 Aug 2012, Julian Reschke wrote:
>>
>> 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.
>
> This is obviously not true since the current text/html registration
> 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

Date: Fri, 10 Aug 2012 17:17:50 +0000 (UTC)
From: Ian Hickson <[email-masked]>
To: Julian Reschke <[email-masked]>
Content-Style-Type: text/css
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

On Fri, 10 Aug 2012, Julian Reschke wrote:
> 
> 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.

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.   `._.-(,_..'--(,_..'`-.;.'

Date: Fri, 10 Aug 2012 12:23:29 +0200
From: Julian Reschke <[email-masked]>
To: "Michael[tm] Smith" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

On 09.08.2012 14:27, Michael[tm] Smith wrote:
> Julian Reschke <[email-masked]>, 2012-08-09 14:07 +0200:
>
>> On 07.08.2012 19:28, Michael[tm] Smith wrote:
>>> Mark Baker <[email-masked]>, 2012-08-07 10:00 -0400:
>>>> I left the WG when HTML5 was deliberately backwards-incompatible,
>>>
>>> Not sure what in particular you thought was deliberately backwards-
>>> incompatible, but OK.
>>
>> 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.

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

Date: Thu, 09 Aug 2012 14:58:30 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

> Michael, Ned,

> >> 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?
> >
> > They probably are.

> 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!

> >> 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'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.

> Ned, is there another list I should monitor to see discussion of another
> 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
> dropped)

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: Paul Libbrecht <[email-masked]>
Date: Thu, 9 Aug 2012 16:44:28 +0200
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

Michael, Ned,

>> 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?
>=20
> They probably are.

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!

>> 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.
>=20
> 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.

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=3D18508

Paul=

Date: Thu, 9 Aug 2012 21:27:13 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

Julian Reschke <[email-masked]>, 2012-08-09 14:07 +0200:

> On 07.08.2012 19:28, Michael[tm] Smith wrote:
> >Mark Baker <[email-masked]>, 2012-08-07 10:00 -0400:
> >>I left the WG when HTML5 was deliberately backwards-incompatible,
> >
> >Not sure what in particular you thought was deliberately backwards-
> >incompatible, but OK.
> 
> 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

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Thu, 09 Aug 2012 14:07:36 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

On 07.08.2012 19:28, Michael[tm] Smith wrote:
> Mark Baker <[email-masked]>, 2012-08-07 10:00 -0400:
>
>> Hi Mike,
>>
>> I left the WG when HTML5 was deliberately backwards-incompatible,
>
> Not sure what in particular you thought was deliberately backwards-
> incompatible, but OK.

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

Best regards, Julian

Date: Wed, 08 Aug 2012 13:47:25 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: "Michael[tm] Smith" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

> Ned Freed <[email-masked]>, 2012-08-07 23:06 -0700:

> > 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.

> 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?

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

				Ned

From: "Markus Lanthaler" <[email-masked]>
To: "'Michael[tm] Smith'" <[email-masked]>
Date: Wed, 8 Aug 2012 18:09:03 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Registration for application/microdata+json

Michael[tm] Smith wrote:
> I see that you've since posted about this over on the whatwg mailing
> list.
> I think that's the best place to discuss it, so let's see how things
> progress over there.

Sure!

--
Markus Lanthaler
@markuslanthaler

Date: Thu, 9 Aug 2012 01:00:47 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: Markus Lanthaler <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration for application/microdata+json

Markus Lanthaler <[email-masked]>, 2012-08-08 11:00 +0200:

> Michael,
> 
> I'm not sure if this is the right place to ask this question, so if it's not
> please tell me.
> I was wondering whether it was considered to use JSON-LD [1] instead of
> creating application/microdata+json. The resulting output would be more or
> less the same.

I see that you've since posted about this over on the whatwg mailing list.
I think that's the best place to discuss it, so let's see how things
progress over there.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Wed, 8 Aug 2012 21:53:35 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

Ned Freed <[email-masked]>, 2012-08-07 23:06 -0700:

> 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.

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

-- 
Michael[tm] Smith http://people.w3.org/mike

From: "Markus Lanthaler" <[email-masked]>
To: "'Michael[tm] Smith'" <[email-masked]>, <[email-masked]>
Date: Wed, 8 Aug 2012 11:00:24 +0200
Subject: Re: [ietf-types] Registration for application/microdata+json

Michael,

I'm not sure if this is the right place to ask this question, so if it's not
please tell me.
I was wondering whether it was considered to use JSON-LD [1] instead of
creating application/microdata+json. The resulting output would be more or
less the same.

For example the following application/microdata+json document:

{
  "items": [
    {
      "id": "http://example.com/id1",
      "type": [ "http://example.com/type1" ],
      "properties": {
        "property1": [ "value1" ],
        "property2": [
          {
            "id": "http://example.com/id2",
            "type": [ 
              "http://example.com/type2", 
              "http://example.com/type3"
            ],
            "properties": {
              "property3": [ "http://example.com/value3" ]
            }
          }
        ]
      }
    }
  ]
}

Could be expressed in JSON-LD as

{
  "@graph": [
    {
      "@id": "http://example.com/id1",
      "@type": [ "http://example.com/type1" ],
      "property1": [ "value1" ],
      "property2": [
        {
          "@id": "http://example.com/id2",
          "@type": [ 
            "http://example.com/type2", 
            "http://example.com/type3"
          ],
          "properties": {
            "property3": [ { "@id": "http://example.com/value3" } ]
          }
        }
      ]
    }
  ]
}

Or, by aliasing JSON-LD's keywords even as which is almost exactly the same
as the application/microdata+json counterpart:

{
  "@context": {
    "id": "@id",
    "type": "@type",
    "items": "@graph"
  },
  "items": [
    {
      "id": "http://example.com/id1",
      "type": [ "http://example.com/type1" ],
      "property1": [ "value1" ],
      "property2": [
        {
          "id": "http://example.com/id2",
          "type": [ 
            "http://example.com/type2", 
            "http://example.com/type3"
          ],
          "properties": {
            "property3": [ { "@id": "http://example.com/value3" } ]
          }
        }
      ]
    }
  ]
}

[1] http://www.w3.org/TR/json-ld-syntax/

--
Markus Lanthaler
@markuslanthaler

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Michael[tm] Smith
> Sent: Tuesday, August 07, 2012 1:50 PM
> To: [email-masked]
> Subject: [ietf-types] Registration for application/microdata+json
> 
> This is a request to register the application/microdata+json media type
> by
> reference to the HTML Microdata specification:
> 
>   http://www.w3.org/TR/microdata/#application-microdata-json
> 
> -----------------------------------------------------------------------
> ----
> Type name:
>   application
> 
> Subtype name:
>   microdata+json
> 
> Required parameters:
>   Same as for application/json [JSON]
> 
> Optional parameters:
>   Same as for application/json [JSON]
> 
> Encoding considerations:
>   8bit (always UTF-8)
> 
> Security considerations:
>   Same as for application/json [JSON]
> 
> Interoperability considerations:
>   Same as for application/json [JSON]
> 
> Published specification:
>   Labeling a resource with the application/microdata+json type asserts
> that
>   the resource is a JSON text that consists of an object with a single
> entry
>   called "items" consisting of an array of entries, each of which
> consists of
>   an object with an entry called "id" whose value is a string, an entry
>   called "type" whose value is another string, and an entry called
>   "properties" whose value is an object whose entries each have a value
>   consisting of an array of either objects or strings, the objects
> being of
>   the same form as the objects in the aforementioned "items" entry.
> Thus, the
>   relevant specifications are the JSON specification and the HTML
> Microdata
>   specification.  [JSON]
> 
> Applications that use this media type:
>   Same as for application/json [JSON]
> 
> Additional information:
>   Magic number(s):
>     Same as for application/json [JSON]
>   File extension(s):
>     Same as for application/json [JSON]
>   Macintosh file type code(s):
>     Same as for application/json [JSON]
> 
> 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 application/microdata+json resources
> have
> the same semantics as when used with application/json (namely, at the
> time
> of writing, no semantics at all). [JSON]
> -----------------------------------------------------------------------
> ----
> 
> --
> Michael[tm] Smith http://people.w3.org/mike
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Tue, 07 Aug 2012 23:06:25 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: "Michael[tm] Smith" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

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 <[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
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Aug 2012 20:17:49 -0500
To: Michael[tm] Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration for application/x-www-form-urlencoded

Hi Michael,

On 07/08/2012, at 6:36 AM, Michael[tm] Smith <[email-masked]> wrote:

> This is a request to register the application/x-www-form-urlencoded =
media
> type by reference to the HTML5 specification:
>=20
>  =
http://www.w3.org/TR/html5/iana.html#application-x-www-form-urlencoded
>=20
[=85]
> Interoperability considerations:
>  Rules for generating and processing application/x-www-form-urlencoded
>  payloads are defined in the HTML5 specification.

HTML4 encouraged =
<http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.=
2> the use of a semi-colon as a delimiter  in some uses of this type. =
AFAICT, HTML5 doesn't say anything about it.

A number of libraries (e.g., Python's urlparse.parse_qs) do treat a =
semicolon as a delimiter, based upon this advice. IME this has led to =
interop problems, as some software thinks it's data, while other =
software thinks it's a delimiter.

It would be good if this could be clarified; e.g., a note to the effect =
that semicolon is NOT a delimiter, even though it was encouraged in the =
past (that makes filing appropriate bugs easier).

That could be done here, or somewhere else in the HTML5 spec.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

Date: Tue, 07 Aug 2012 15:25:03 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: "Michael[tm] Smith" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

> Paul Libbrecht <[email-masked]>, 2012-08-07 15:14 +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

> 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?

They probably are.

> 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'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

Date: Wed, 8 Aug 2012 02:28:41 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: Mark Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

Mark Baker <[email-masked]>, 2012-08-07 10:00 -0400:

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

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

> 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 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

> 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"

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.

> 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).

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

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Wed, 8 Aug 2012 02:14:21 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

Paul Libbrecht <[email-masked]>, 2012-08-07 15:14 +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

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.

> 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?).

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

-- 
Michael[tm] Smith http://people.w3.org/mike

Sender: [email-masked]
Date: Tue, 7 Aug 2012 10:00:25 -0400
From: Mark Baker <[email-masked]>
To: "Michael[tm] Smith" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

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: Paul Libbrecht <[email-masked]>
Date: Tue, 7 Aug 2012 15:14:36 +0200
To: Michael[tm] Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Update to text/html registration

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=FBt 2012 =E0 13:16, Michael[tm] Smith a =E9crit :

> Please update the registration for the text/html media type to =
reference
> the HTML5 specification instead of RFC 2854.
>=20
>  http://www.w3.org/TR/html5/iana.html#text-html
>=20
> =
--------------------------------------------------------------------------=
-
> Type name:
>  text
>=20
> Subtype name:
>  html
>=20
> Required parameters:
>  No required parameters
>=20
> 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]
>=20
> Encoding considerations:
>  8bit (see the section on character encoding declarations)
>=20
> 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:
>=20
>  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.
>=20
>  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.
>=20
>  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.
>=20
>  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.
>=20
> Interoperability considerations:
>  Rules for processing both conforming and non-conforming content are
>  defined in the HTML5 specification.
>=20
> 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.
>=20
> Applications that use this media type:
>  Web browsers, tools for processing Web content, HTML authoring tools,
>  search engines, validators.
>=20
> 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.
>=20
>    File extension(s):
>      "html" and "htm" are commonly, but certainly not exclusively, =
used as
>      the extension for HTML documents.
>=20
>    Macintosh file type code(s):
>      TEXT
>=20
> Person & email address to contact for further information:
>   Michael[tm] Smith <[email-masked]>
>=20
> Intended usage:
>  Common
>=20
> Restrictions on usage:
>  No restrictions apply.
>=20
> Author:
>  Ian Hickson <[email-masked]>
>=20
> Change controller:
>  W3C
>=20
> Fragment identifiers used with text/html resources either refer to the
> indicated part of the document or provide state information for =
in-page
> scripts.
> =
--------------------------------------------------------------------------=
-
>=20
> --=20
> Michael[tm] Smith http://people.w3.org/mike
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Tue, 7 Aug 2012 20:50:27 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration for application/microdata+json

This is a request to register the application/microdata+json media type by
reference to the HTML Microdata specification:

  http://www.w3.org/TR/microdata/#application-microdata-json

---------------------------------------------------------------------------
Type name:
  application

Subtype name:
  microdata+json

Required parameters:
  Same as for application/json [JSON]

Optional parameters:
  Same as for application/json [JSON]

Encoding considerations:
  8bit (always UTF-8)

Security considerations:
  Same as for application/json [JSON]

Interoperability considerations:
  Same as for application/json [JSON]

Published specification:
  Labeling a resource with the application/microdata+json type asserts that
  the resource is a JSON text that consists of an object with a single entry
  called "items" consisting of an array of entries, each of which consists of
  an object with an entry called "id" whose value is a string, an entry
  called "type" whose value is another string, and an entry called
  "properties" whose value is an object whose entries each have a value
  consisting of an array of either objects or strings, the objects being of
  the same form as the objects in the aforementioned "items" entry. Thus, the
  relevant specifications are the JSON specification and the HTML Microdata
  specification.  [JSON]

Applications that use this media type:
  Same as for application/json [JSON]

Additional information:
  Magic number(s):
    Same as for application/json [JSON]
  File extension(s):
    Same as for application/json [JSON]
  Macintosh file type code(s):
    Same as for application/json [JSON]

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 application/microdata+json resources have
the same semantics as when used with application/json (namely, at the time
of writing, no semantics at all). [JSON]
---------------------------------------------------------------------------

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Tue, 7 Aug 2012 20:45:52 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration for text/event-stream

This is a request to register the text/event-stream media type by reference
to the Server-Sent Events specification:

  http://www.w3.org/TR/eventsource/#text-event-stream

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

Subtype name:
  event-stream

Required parameters:
  No parameters

Optional parameters:
  charset
    The charset parameter may be provided. The parameter's value must be
    "utf-8". This parameter serves no purpose; it is only allowed for
    compatibility with legacy servers.

Encoding considerations:
  8bit (always UTF-8)

Security considerations:
  An event stream from an origin distinct from the origin of the content
  consuming the event stream can result in information leakage. To avoid
  this, user agents are required to apply CORS semantics. [CORS]

  Event streams can overwhelm a user agent; a user agent is expected to
  apply suitable restrictions to avoid depleting local resources because of
  an overabundance of information from an event stream.

  Servers can be overwhelmed if a situation develops in which the server is
  causing clients to reconnect rapidly. Servers should use a 5xx status
  code to indicate capacity problems, as this will prevent conforming
  clients from reconnecting automatically.

Interoperability considerations:
  Rules for processing both conforming and non-conforming content are
  defined in the Server-Sent Events specification.

Published specification:
  The Server-Sent Events specification is the relevant specification.

Applications that use this media type:
  Web browsers and tools using Web services.

Additional information:
  Magic number(s):
    No sequence of bytes can uniquely identify an event stream.

  File extension(s):
    No specific file extensions are recommended for this type.

  Macintosh file type code(s):
    No specific Macintosh file type codes are recommended for this type.

Person & email address to contact for further information:
  Michael[tm] Smith <[email-masked]>

Intended usage:
  Common

Restrictions on usage:
  This format is only expected to be used by dynamic open-ended streams
  served using HTTP or a similar protocol. Finite resources are not
  expected to be labeled with this type.

Author:
  Ian Hickson <[email-masked]>

Change controller:
  W3C

Fragment identifiers have no meaning with text/event-stream resources.
---------------------------------------------------------------------------

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Tue, 7 Aug 2012 20:40:12 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration for text/cache-manifest

This is a request to register the text/cache-manifest media type by
reference to the HTML5 specification:

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

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

Subtype name:
  cache-manifest

Required parameters:
  No parameters

Optional parameters:
  No parameters

Encoding considerations:
  8bit (always UTF-8)

Security considerations:
  Cache manifests themselves pose no immediate risk unless sensitive
  information is included within the manifest. Implementations, however,
  are required to follow specific rules when populating a cache based on a
  cache manifest, to ensure that certain origin-based restrictions are
  honored.  Failure to correctly implement these rules can result in
  information leakage, cross-site scripting attacks, and the like.

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

Published specification:
  The HTML5 specification is the relevant specification.

Applications that use this media type:
  Web browsers.

Additional information:
  Magic number(s):
    Cache manifests begin with the string "CACHE MANIFEST", followed by
    either a U+0020 SPACE character, a "tab" (U+0009) character, a "LF"
    (U+000A) character, or a "CR" (U+000D) character.
    
  File extension(s):
    "appcache"

  Macintosh file type code(s):
    No specific Macintosh file type codes are recommended for this type.

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 have no meaning with text/cache-manifest resources.
---------------------------------------------------------------------------

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Tue, 7 Aug 2012 20:36:02 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration for application/x-www-form-urlencoded

This is a request to register the application/x-www-form-urlencoded media
type by reference to the HTML5 specification:

  http://www.w3.org/TR/html5/iana.html#application-x-www-form-urlencoded

---------------------------------------------------------------------------
Type name:
  application

Subtype name:
  x-www-form-urlencoded

Required parameters:
  No parameters

Optional parameters:
  No parameters

Encoding considerations:
  7bit (US-ASCII encoding of octets that themselves can be encoding text
  using any ASCII-compatible character encoding)

Security considerations:
  In isolation, an application/x-www-form-urlencoded payload poses no
  security risks. However, as this type is usually used as part of a form
  submission, all the risks that apply to HTML forms need to be considered
  in the context of this type.

Interoperability considerations:
  Rules for generating and processing application/x-www-form-urlencoded
  payloads are defined in the HTML5 specification.

Published specification:
  The HTML specification is the relevant specification. Algorithms for
  encoding and decoding are defined.

Applications that use this media type:
  Web browsers and servers.

Additional information:
  Magic number(s):
    There is no reliable mechanism for recognizing
    application/x-www-form-urlencoded payloads.

  File extension(s):
    Not applicable.

  Macintosh file type code(s):
    Not applicable.

Person & email address to contact for further information:
  Michael[tm] Smith <[email-masked]>

Intended usage:
  Common

Restrictions on usage:
  This type is only intended to be used to describe HTML form submission
  payloads.

Author:
  Ian Hickson <[email-masked]>

Change controller:
  W3C

Fragment identifiers have no meaning with the application/x-www-form-urlencoded
type as this type is only used for uploaded payloads that do not have URL
identifiers.
---------------------------------------------------------------------------

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Tue, 7 Aug 2012 20:35:21 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration for multipart/x-mixed-replace

This is a request to register the multipart/x-mixed-replace media type
by reference to the HTML5 specification:

  http://www.w3.org/TR/html5/iana.html#multipart-x-mixed-replace

---------------------------------------------------------------------------
Type name:
  multipart

Subtype name:
  x-mixed-replace

Required parameters:
  boundary (defined in RFC2046) [RFC2046]

Optional parameters:
  No optional parameters.

Encoding considerations:
  binary

Security considerations:
  Subresources of a multipart/x-mixed-replace resource can be of any type,
  including types with non-trivial security implications such as text/html.

Interoperability considerations:
  None.

Published specification:
  The HTML5 specification describes processing rules for Web browsers.
  Conformance requirements for generating resources with this type are the
  same as for multipart/mixed. [RFC2046]

Applications that use this media type:
    This type is intended to be used in resources generated by Web servers,
    for consumption by Web browsers.

Additional information:
  Magic number(s):
    No sequence of bytes can uniquely identify a multipart/x-mixed-replace
    resource.

  File extension(s):
    No specific file extensions are recommended for this type.

  Macintosh file type code(s):
    No specific Macintosh file type codes are recommended for this type.

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 multipart/x-mixed-replace resources apply to
each body part as defined by the type used by that body part.
---------------------------------------------------------------------------

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Tue, 7 Aug 2012 20:21:41 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Update to application/xhtml+xml media type

Please update the registration for the application/xhtml+xml media type to
reference the HTML5 spec instead of RFC 3236.

  http://www.w3.org/TR/html5/iana.html#application-xhtml-xml

---------------------------------------------------------------------------
Type name:
  application

Subtype name:
  xhtml+xml

Required parameters:
  Same as for application/xml [RFC3023]

Optional parameters:
  Same as for application/xml [RFC3023]

Encoding considerations:
  Same as for application/xml [RFC3023]

Security considerations:
  Same as for application/xml [RFC3023]

Interoperability considerations:
  Same as for application/xml [RFC3023]

Published specification:
  Labeling a resource with the application/xhtml+xml type asserts that the
  resource is an XML document that likely has a root element from the HTML
  namespace. Thus, the relevant specifications are the XML specification,
  the Namespaces in XML specification, and the HTML5 specification.

Applications that use this media type:
  Same as for application/xml [RFC3023]

Additional information:
  Magic number(s):
    Same as for application/xml [RFC3023]
  File extension(s):
    "xhtml" and "xht" are sometimes used as extensions for XML resources
    that have a root element from the HTML namespace.

  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 application/xhtml+xml resources have the
same semantics as with any XML MIME type. [RFC3023]
---------------------------------------------------------------------------

-- 
Michael[tm] Smith http://people.w3.org/mike

Date: Tue, 7 Aug 2012 20:16:49 +0900
From: "Michael[tm] Smith" <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Update to text/html registration

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