[whatwg] FW: [[IANA #598700] Registration for multipart/x-mixed-replace media type]

[Michael[tm] Smith]

Hixie,

FYI, comments back from (nameless) IESG designated expert on the
multipart/x-mixed-replace media type description in the HTML spec.

  --Mike

----- Forwarded message from Amanda Baber via RT <iana-mime at iana.org> -----

Subject: [IANA #598700] Registration for multipart/x-mixed-replace media type
From: Amanda Baber via RT <iana-mime at iana.org>
To: mike at w3.org
Date: Mon, 8 Oct 2012 18:49:49 +0000

Dear Michael,

The IESG-designated expert has reviewed your application and returned 
the inline comments below. Please reply to this email within 30 days 
(i.e. by 7 November) with a revised application. 

If you have any questions, please don't hesitate to contact us.

Best regards,

Amanda Baber
IANA Analyst
ICANN

> 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

Multipart types in general don't really have encoding considerations;
the subparts do. However, in some cases there are additional
restrictions on the encoding of multiparts used in some environments,
and this properly should be noted here. I take the specification of
binary here to mean there are no such restrictions, but it would be
better to make this explicit. Following the example of
multipart/form-data in RFC 2388, I suggest saying something like:

  No additional considerations other than as for other multipart types.

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

This covers the content within the multipart, not the semantics and
security considerations of the multipart structure itself, which even
after reading section 5.5.5 and other material in the specification
several times, I confess I don't fully understand. 

Regardless of what that difference is between this type and
multipart/mixed - and there clearly is a difference -  it potentially
gives rise to its own security considerations that need to be described
here, just as, say multipart/alternative has very different security
considerations than multipart/mixed. And if it doesn't, then that should
also be pointed out.

> Interoperability considerations:
> None.

> Published specification:
> The HTML5 specification describes processing rules for Web browsers.

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

Indeed it does, but this points at the registration section only, which
only contains the registration, not the actual processing rules. Since
the section where the processing rules are described could easily change
I think the best thing to do is refer to the entire specification here:

		http://www.w3.org/TR/html5

> 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 <mike at w3.org>

> Intended usage:
> Common

> Restrictions on usage:
> No restrictions apply.

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

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




----- End forwarded message -----

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