ISSUE-53: Need to update media type registrations

using RAISED to represent lower priority as discussed in http://lists.w3.org/Archives/Public/public-html-wg-issue-tracking/2008Aug/0005.html

As of August 2009, the editor's draft contains the registration in-line, which defeats the ourpose of having the registry apply to all HTML family members.

Moving to PR Blocker per mailing list discussion.

Can't remember why this was closed. Moving back to RAISED status.

I just received note from the IANA that both application/x-www-form-urlencoded
and text/cache-manifest have been accepted for registration. The other
three are still with the experts.

application/x-www-form-urlencoded
https://tools.iana.org/public-view/viewticket/750877
text/cache-manifest
https://tools.iana.org/public-view/viewticket/750878
application/xhtml+xml
https://tools.iana.org/public-view/viewticket/750876
multipart/x-mixed-replace
https://tools.iana.org/public-view/viewticket/750875
text/html
https://tools.iana.org/public-view/viewticket/750870

multipart/x-mixed-replace is now registered

Latest comments on xhtml+xml:

> Name : Robin Berjon

> Email : robin@w3.org

> MIME media type name : Application

> MIME subtype name : Standards Tree - xhtml+xml

> Required parameters : Same as for application/xml [RFC7303]

RFC 7303 doesn't specify any required parameters for application/xml,
so this should just be "none". (There's no sense in having a pointer to
nothing.)

> Optional parameters :

> charset: same as for application/xml [RFC7303]

> profile: deprecated as the notion of XHTML profiles has been obsoleted
> in HTML5

It's fine to decprecate the parameter, but pointer needs to be
retained to the original definitition. I suggest adding "See section 8 of
RFC 3236 for additional information about how this parameter was defined."
or something along those lines.

> Encoding considerations : 8bit

Unless you're saying that application/xhtml+xml can't be encoded in utf-16 -
which I very much doubt - this is incorrect. I suggest saying "same as for
application/xml [RFC 7303]", which would match the previous registration.

> Security considerations :
> Same as for application/xml [RFC7303]

This is insufficient. I suggest copying and updating what's in RFC 3236,
something like:

The considerations for "text/html" as specified in http://www.w3.org/TR/html
and for 'application/xml' as specified in [RFC 7303], also hold for
'application/xhtml+xml'.

In addition, because of the extensibility features for XHTML as
provided by XHTML Modularization, it is possible that
'application/xhtml+xml' may describe content that has security
implications beyond those described here. However, if the user agent
follows the user agent conformance rules in http://www.w3.org/TR/xhtml2/,
this content will be ignored. Only in the case where the user agent
recognizes and processes the additional content, or where further
processing of that content is dispatched to other processors, would
security issues potentially arise.

I don't know if the updates to the references I've done are correct, but
it's a starting point.

> Interoperability considerations :
> Same as for application/xml [RFC7303]

This is clearly incomplete. Perhaps the text in RFC 3216 can be updated to
fit here.

> 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 http://www.w3.org/TR/html.

Isn't a refernce to http://www.w3.org/TR/xhtml2/ also appropriate?

> Applications which use this media :
> Same as for application/xml [RFC7303]

This is clearly incorrect; perhaps some of the text from RFC 3236 can be
resued here.

> Fragment identifier considerations :
> Same as for application/xml [RFC7303]

> Restrictions on usage :
> No restrictions apply.

> Provisional registration? (standards tree only) :
> No.


> Additional information :

> 1. Deprecated alias names for this type : N/A
> 2. Magic number(s) : Same as for application/xml [RFC7303]

The text from RFC 3236 needs to be updated and reused here.

> 3. File extension(s) : "xhtml" and "xht" are sometimes used.
> 4. Macintosh file type code : TEXT
> 5. Object Identifiers: N/A



> Person to contact for further information :

> 1. Name : Robin Berjon
> 2. Email : robin@w3.org

> Intended usage : Common
> N/A

> Author/Change controller : Author/Change controller : Author:
> Ian Hickson <ian@hixie.ch>

> Change controller:
> W3C

Re: [IANA #750876] Request for MIME media type.eml
Subject:
Re: [IANA #750876] Request for MIME media type Application/Standards Tree - xhtml+xml
From:
"robin@w3.org via RT" <iana-mime@iana.org>
Date:
09/08/2014 05:37 AM
To:
plh@w3.org

Hi Amanda,

please find my reply to the expert's concerns below, followed by an
updated registration.

Thanks for the review!

On 27/08/2014 02:35 , Amanda Baber via RT wrote:
>> Required parameters : Same as for application/xml [RFC7303]
>
> RFC 7303 doesn't specify any required parameters for application/xml,
> so this should just be "none". (There's no sense in having a pointer to
> nothing.)

Ok, updated.

>> Optional parameters :
>
>> charset: same as for application/xml [RFC7303]
>
>> profile: deprecated as the notion of XHTML profiles has been obsoleted
>> in HTML5
>
> It's fine to decprecate the parameter, but pointer needs to be
> retained to the original definitition. I suggest adding "See section 8 of
> RFC 3236 for additional information about how this parameter was defined."
> or something along those lines.

Good point, I've added that.

>> Encoding considerations : 8bit
>
> Unless you're saying that application/xhtml+xml can't be encoded in utf-16 -
> which I very much doubt - this is incorrect. I suggest saying "same as for
> application/xml [RFC 7303]", which would match the previous registration.

That's not what we're saying, but the value space that is available to
us for this field is a drop-down box enumeration. My understanding is
that "8bit" is just a way of saying that this isn't an old-school 7bit
ASCII text format.

>> Security considerations :
>> Same as for application/xml [RFC7303]
>
> This is insufficient. I suggest copying and updating what's in RFC 3236,
> something like:
>
> The considerations for "text/html" as specified in http://www.w3.org/TR/html
> and for 'application/xml' as specified in [RFC 7303], also hold for
> 'application/xhtml+xml'.
>
> In addition, because of the extensibility features for XHTML as
> provided by XHTML Modularization, it is possible that
> 'application/xhtml+xml' may describe content that has security
> implications beyond those described here. However, if the user agent
> follows the user agent conformance rules in http://www.w3.org/TR/xhtml2/,
> this content will be ignored. Only in the case where the user agent
> recognizes and processes the additional content, or where further
> processing of that content is dispatched to other processors, would
> security issues potentially arise.
>
> I don't know if the updates to the references I've done are correct, but
> it's a starting point.

I have included the first part of your proposal, which makes sense, but
not the second part. XHTML2 and XHTML Modularization are both completely
abandoned and buried efforts with no bearing on implementations
whatsoever. Including them is at best uninformative, and would likely
lead to confusion (or possibly would make people think that the
registration is not up to date by several years).

>> Interoperability considerations :
>> Same as for application/xml [RFC7303]
>
> This is clearly incomplete. Perhaps the text in RFC 3216 can be updated to
> fit here.

Fair enough. I have updated this field with the same text as for the
text/html registration since the same situation really applies to both
(including the extensibility afforded by XML which is now available in
HTML).

>> 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 http://www.w3.org/TR/html.
>
> Isn't a refernce to http://www.w3.org/TR/xhtml2/ also appropriate?

Not at all, XHTML2 is a dead effort. As indicated above, mentioning it
would be confusing and possibly induce distrust in this registration.

>> Applications which use this media :
>> Same as for application/xml [RFC7303]
>
> This is clearly incorrect; perhaps some of the text from RFC 3236 can be
> resued here.

Likewise, I've reused the text from the text/html registration as it is
what applies.

>> Additional information :
>
>> 1. Deprecated alias names for this type : N/A
>> 2. Magic number(s) : Same as for application/xml [RFC7303]
>
> The text from RFC 3236 needs to be updated and reused here.

The RFC 3236 text has cases in which it is incorrect in today's usage of
(X)HTML so it can't be reused much. Thankfully this text was updated for
text/html and I have updated the registration with an adapted version of
the same.


-------------------------------------------------------------------------
Name : Robin Berjon

Email : robin@w3.org

MIME media type name : Application

MIME subtype name : Standards Tree - xhtml+xml

Required parameters : none

Optional parameters :

charset: same as for application/xml [RFC7303]

profile: deprecated as the notion of XHTML profiles has been obsoleted
in HTML5. See section 8 of RFC 3236 for additional information about how
this parameter was defined.

Encoding considerations : 8bit

Security considerations :
The considerations for "text/html" as specified in
http://www.w3.org/TR/html and for 'application/xml' as specified in [RFC
7303], also hold for 'application/xhtml+xml'.

Interoperability considerations :
Rules for processing both conforming and non-conforming content are
defined in http://www.w3.org/TR/html.


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 http://www.w3.org/TR/html.

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

Fragment identifier considerations :
Same as for application/xml [RFC7303]

Restrictions on usage :
No restrictions apply.

Provisional registration? (standards tree only) :
No.


Additional information :

1. Deprecated alias names for this type : N/A
2. Magic number(s) : No sequence of bytes can uniquely identify an XHTML
document. More information on detecting XHTML documents is available in
the MIME Sniffing specification.
3. File extension(s) : "xhtml" and "xht" are sometimes used.
4. Macintosh file type code : TEXT
5. Object Identifiers: N/A



Person to contact for further information :

1. Name : Robin Berjon
2. Email : robin@w3.org

Intended usage : Common
N/A

Author/Change controller : Author/Change controller : Author:
Ian Hickson <ian@hixie.ch>

Change controller:
W3C



-- Robin Berjon - http://berjon.com/ - @robinberjon

text/html has been updated: http://www.iana.org/assignments/media-types/text/html

On 27/08/2014 02:35 , Amanda Baber via RT wrote:
>> Required parameters : Same as for application/xml [RFC7303]
>
> RFC 7303 doesn't specify any required parameters for application/xml,
> so this should just be "none". (There's no sense in having a pointer to
> nothing.)

Ok, updated.

>> Optional parameters :
>
>> charset: same as for application/xml [RFC7303]
>
>> profile: deprecated as the notion of XHTML profiles has been obsoleted
>> in HTML5
>
> It's fine to decprecate the parameter, but pointer needs to be
> retained to the original definitition. I suggest adding "See section 8 of
> RFC 3236 for additional information about how this parameter was defined."
> or something along those lines.

Good point, I've added that.

>> Encoding considerations : 8bit
>
> Unless you're saying that application/xhtml+xml can't be encoded in utf-16 -
> which I very much doubt - this is incorrect. I suggest saying "same as for
> application/xml [RFC 7303]", which would match the previous registration.

That's not what we're saying, but the value space that is available to us for this field is a drop-down box enumeration. My understanding is that "8bit" is just a way of saying that this isn't an old-school 7bit ASCII text format.

>> Security considerations :
>> Same as for application/xml [RFC7303]
>
> This is insufficient. I suggest copying and updating what's in RFC 3236,
> something like:
>
> The considerations for "text/html" as specified in http://www.w3.org/TR/html
> and for 'application/xml' as specified in [RFC 7303], also hold for
> 'application/xhtml+xml'.
>
> In addition, because of the extensibility features for XHTML as
> provided by XHTML Modularization, it is possible that
> 'application/xhtml+xml' may describe content that has security
> implications beyond those described here. However, if the user agent
> follows the user agent conformance rules in http://www.w3.org/TR/xhtml2/,
> this content will be ignored. Only in the case where the user agent
> recognizes and processes the additional content, or where further
> processing of that content is dispatched to other processors, would
> security issues potentially arise.
>
> I don't know if the updates to the references I've done are correct, but
> it's a starting point.

I have included the first part of your proposal, which makes sense, but not the second part. XHTML2 and XHTML Modularization are both completely abandoned and buried efforts with no bearing on implementations whatsoever. Including them is at best uninformative, and would likely lead to confusion (or possibly would make people think that the registration is not up to date by several years).

>> Interoperability considerations :
>> Same as for application/xml [RFC7303]
>
> This is clearly incomplete. Perhaps the text in RFC 3216 can be updated to
> fit here.

Fair enough. I have updated this field with the same text as for the text/html registration since the same situation really applies to both (including the extensibility afforded by XML which is now available in HTML).

>> 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 http://www.w3.org/TR/html.
>
> Isn't a refernce to http://www.w3.org/TR/xhtml2/ also appropriate?

Not at all, XHTML2 is a dead effort. As indicated above, mentioning it would be confusing and possibly induce distrust in this registration.

>> Applications which use this media :
>> Same as for application/xml [RFC7303]
>
> This is clearly incorrect; perhaps some of the text from RFC 3236 can be
> resued here.

Likewise, I've reused the text from the text/html registration as it is what applies.

>> Additional information :
>
>> 1. Deprecated alias names for this type : N/A
>> 2. Magic number(s) : Same as for application/xml [RFC7303]
>
> The text from RFC 3236 needs to be updated and reused here.

The RFC 3236 text has cases in which it is incorrect in today's usage of (X)HTML so it can't be reused much. Thankfully this text was updated for text/html and I have updated the registration with an adapted version of the same.


-------------------------------------------------------------------------
Name : Robin Berjon

Email : robin@w3.org

MIME media type name : Application

MIME subtype name : Standards Tree - xhtml+xml

Required parameters : none

Optional parameters :

charset: same as for application/xml [RFC7303]

profile: deprecated as the notion of XHTML profiles has been obsoleted in HTML5. See section 8 of RFC 3236 for additional information about how this parameter was defined.

Encoding considerations : 8bit

Security considerations :
The considerations for "text/html" as specified in http://www.w3.org/TR/html and for 'application/xml' as specified in [RFC 7303], also hold for 'application/xhtml+xml'.

Interoperability considerations :
Rules for processing both conforming and non-conforming content are defined in http://www.w3.org/TR/html.


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 http://www.w3.org/TR/html.

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

Fragment identifier considerations :
Same as for application/xml [RFC7303]

Restrictions on usage :
No restrictions apply.

Provisional registration? (standards tree only) :
No.


Additional information :

1. Deprecated alias names for this type : N/A
2. Magic number(s) : No sequence of bytes can uniquely identify an XHTML document. More information on detecting XHTML documents is available in the MIME Sniffing specification.
3. File extension(s) : "xhtml" and "xht" are sometimes used.
4. Macintosh file type code : TEXT
5. Object Identifiers: N/A



Person to contact for further information :

1. Name : Robin Berjon
2. Email : robin@w3.org

Intended usage : Common
N/A

Author/Change controller : Author/Change controller : Author:
Ian Hickson <ian@hixie.ch>

Change controller:
W3C

[[
For application/xhtml_+xml:

The expert has approved this request, provided the encoding considerations section is changed from "8bit" to "binary." Does this work? See below.
]]

http://www.iana.org/assignments/media-types/media-types.xhtml#application
has been updated. We're done.