ISSUE-53: Need to update media type registrations

mediatypereg

Need to update media type registrations

State:
OPEN
Product:
HTML5 Spec - PR Blockers
Raised by:
Julian Reschke
Opened on:
2008-06-23
Description:
Once HTML5 is ready, the IETF documents defining the media types text/html (RFC2854) and application/xhtml+xml (RFC326) should be updated.

Also, NOTE-xhtml-media-types-20020801 should be updated as well.

See discussion in <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5744>.
Related Actions Items:
No related actions
Related emails:
  1. Re: TAG ACTION-407 -- text/html media type and legacy (from mjs@apple.com on 2010-04-22)
  2. Re: TAG ACTION-407 -- text/html media type and legacy (from ht@inf.ed.ac.uk (Henry S. Thompson) on 2010-04-15)
  3. Re: Re-registration of text/html (from mjs@apple.com on 2010-02-21)
  4. Re: no change proposal for ISSUE-55, but a new plan for @profile (from jonas@sicking.cc on 2010-02-21)
  5. Re: no change proposal for ISSUE-55, but a new plan for @profile (from julian.reschke@gmx.de on 2010-02-21)
  6. Re: no change proposal for ISSUE-55, but a new plan for @profile (from xn--mlform-iua@xn--mlform-iua.no on 2010-02-21)
  7. Re: no change proposal for ISSUE-55, but a new plan for @profile (from mjs@apple.com on 2010-02-20)
  8. Re: Re-registration of text/html (from julian.reschke@gmx.de on 2010-02-20)
  9. Re-registration of text/html (from xn--mlform-iua@xn--mlform-iua.no on 2010-02-20)
  10. Re: no change proposal for ISSUE-55, but a new plan for @profile (from julian.reschke@gmx.de on 2010-02-20)
  11. Re: ISSUE-53 - HTML Weekly Tracker (from mjs@apple.com on 2010-02-02)
  12. ISSUE-53 - HTML Weekly Tracker (from julian.reschke@gmx.de on 2010-02-02)
  13. Legacy Doctype and Doctype Versioning (from masinter@adobe.com on 2010-01-19)
  14. obsoleting and the text/html MIME type (re Taking another round at @summary) (from masinter@adobe.com on 2010-01-07)
  15. Re: How to track issues that block PR but not Last Call (was Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03) (from mjs@apple.com on 2009-09-23)
  16. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-14)
  17. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from distobj@acm.org on 2009-09-05)
  18. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from tai@g5n.co.uk on 2009-09-03)
  19. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-09-03)
  20. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-09-03)
  21. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-09-03)
  22. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from tai@g5n.co.uk on 2009-09-03)
  23. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-09-03)
  24. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-03)
  25. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-09-03)
  26. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-03)
  27. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from distobj@acm.org on 2009-09-03)
  28. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-02)
  29. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from distobj@acm.org on 2009-09-02)
  30. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-09-02)
  31. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from distobj@acm.org on 2009-09-01)
  32. RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from tai@g5n.co.uk on 2009-09-01)
  33. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-01)
  34. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-01)
  35. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-09-01)
  36. needed updates: RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from jimjjewett@gmail.com on 2009-08-31)
  37. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-08-31)
  38. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from distobj@acm.org on 2009-08-31)
  39. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-31)
  40. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-08-31)
  41. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  42. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-31)
  43. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  44. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  45. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  46. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-31)
  47. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  48. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-08-31)
  49. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-31)
  50. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from tai@g5n.co.uk on 2009-08-31)
  51. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  52. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-08-31)
  53. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  54. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  55. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-31)
  56. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-08-31)
  57. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  58. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-31)
  59. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-31)
  60. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-31)
  61. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from distobj@acm.org on 2009-08-30)
  62. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-28)
  63. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from tai@g5n.co.uk on 2009-08-28)
  64. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-28)
  65. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from jonas@sicking.cc on 2009-08-28)
  66. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-28)
  67. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-28)
  68. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mike@w3.org on 2009-08-28)
  69. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-27)
  70. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-27)
  71. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from simonp@opera.com on 2009-08-27)
  72. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-27)
  73. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-27)
  74. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-27)
  75. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from smedero@uw.edu on 2009-08-27)
  76. {minutes} HTML WG telcon 2009-08-27 (from annevk@opera.com on 2009-08-27)
  77. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-27)
  78. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-26)
  79. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-26)
  80. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-26)
  81. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-26)
  82. {agenda} HTML WG telcon 2009-08-27 *PLEASE-READ* (from rubys@intertwingly.net on 2009-08-26)
  83. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-26)
  84. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-26)
  85. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-26)
  86. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-25)
  87. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  88. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-25)
  89. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  90. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-25)
  91. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-25)
  92. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  93. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  94. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-25)
  95. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-25)
  96. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  97. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-25)
  98. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  99. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-25)
  100. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-25)
  101. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-25)
  102. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-25)
  103. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-25)
  104. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-25)
  105. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-24)
  106. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-24)
  107. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-24)
  108. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-24)
  109. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-24)
  110. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-24)
  111. RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from masinter@adobe.com on 2009-08-24)
  112. Re: How to track issues that block PR but not Last Call (was Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03) (from connolly@w3.org on 2009-08-24)
  113. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-24)
  114. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-24)
  115. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-24)
  116. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-24)
  117. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-24)
  118. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from annevk@opera.com on 2009-08-24)
  119. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-24)
  120. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-24)
  121. RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-24)
  122. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-23)
  123. RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from masinter@adobe.com on 2009-08-23)
  124. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-23)
  125. RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from masinter@adobe.com on 2009-08-23)
  126. Re: Path to Last Call (was closing various issues) (from faulkner.steve@gmail.com on 2009-08-23)
  127. Re: Path to Last Call (was closing various issues) (from mjs@apple.com on 2009-08-23)
  128. Re: Path to Last Call (was closing various issues) (from rubys@intertwingly.net on 2009-08-23)
  129. How to track issues that block PR but not Last Call (was Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03) (from mjs@apple.com on 2009-08-22)
  130. Re: Path to Last Call (was closing various issues) (from mjs@apple.com on 2009-08-22)
  131. Proposal for Lazy Consensus: Details of Media Type Registration (from mjs@apple.com on 2009-08-22)
  132. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-22)
  133. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-22)
  134. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-22)
  135. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-22)
  136. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-22)
  137. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-22)
  138. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from fielding@gbiv.com on 2009-08-21)
  139. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-21)
  140. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from rubys@intertwingly.net on 2009-08-21)
  141. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-21)
  142. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-21)
  143. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-21)
  144. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-21)
  145. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-21)
  146. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-21)
  147. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-21)
  148. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-21)
  149. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from hsivonen@iki.fi on 2009-08-21)
  150. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-21)
  151. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from ian@hixie.ch on 2009-08-21)
  152. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-21)
  153. Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from julian.reschke@gmx.de on 2009-08-21)
  154. ISSUE-53: mediatypereg - suggest closing on 2009-09-03 (from mjs@apple.com on 2009-08-20)
  155. Re: Reuse of 1999 XHTML namespace, text/html and application/xhtml+xml media types (from rubys@intertwingly.net on 2009-02-19)
  156. Re: Reuse of 1999 XHTML namespace, text/html and application/xhtml+xml media types (from connolly@w3.org on 2009-02-18)
  157. Re: ISSUE-53 (mediatypereg): Need to update media type registrations [HTML 5 spec] (from lachlan.hunt@lachy.id.au on 2008-06-23)
  158. ISSUE-53 (mediatypereg): Need to update media type registrations [HTML 5 spec] (from sysbot+tracker@w3.org on 2008-06-23)

Related notes:

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

Dan Connolly, 22 Aug 2008, 15:45:02

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.

Julian Reschke, 13 Aug 2009, 18:33:17

Moving to PR Blocker per mailing list discussion.

Maciej Stachowiak, 24 Sep 2009, 06:39:35

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

Maciej Stachowiak, 2 Feb 2010, 23:07:06

[MikeSmith]: see related TAG action: http://www.w3.org/2001/tag/group/track/actions/364

24 Feb 2010, 10:46:41

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.

Robin Berjon, 15 May 2014, 15:04:55

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

Philippe Le Hégaret, 15 May 2014, 15:17:00

multipart/x-mixed-replace is now registered

Philippe Le Hégaret, 29 Aug 2014, 17:56:29

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

Philippe Le Hégaret, 29 Aug 2014, 18:01:13

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

Sam Ruby, 9 Sep 2014, 14:58:01

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

Sam Ruby, 9 Sep 2014, 14:59:03

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, 9 Sep 2014, 15:02:09

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

Philippe Le Hégaret, 17 Oct 2014, 15:16:19

Changelog:

Created issue 'Need to update media type registrations' nickname mediatypereg owned by Julian Reschke on product HTML 5 spec, description 'Once HTML5 is ready, the IETF documents defining the media types text/html (RFC2854) and application/xhtml+xml (RFC326) should be updated.

Also, NOTE-xhtml-media-types-20020801 should be updated as well.

See discussion in <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5744>.' non-public

Julian Reschke, 23 Jun 2008, 07:14:05

Status changed to 'raised'

Dan Connolly, 22 Aug 2008, 15:45:02

Status changed to 'pending review'

Sam Ruby, 23 Aug 2009, 10:42:47

Product changed to HTML5 Spec - PR Blockers

Maciej Stachowiak, 24 Sep 2009, 06:39:35

Status changed to 'closed'

Maciej Stachowiak, 19 Nov 2009, 17:12:22

Status changed to 'raised'

Maciej Stachowiak, 2 Feb 2010, 23:07:05

Status changed to 'open'

Philippe Le Hégaret, 15 May 2014, 14:23:15


Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Chairs, Michael[tm] Smith <mike@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.325 2014-09-10 21:42:02 ted Exp $