[IANA #666222] Request for MIME media type Application/Standards Tree - provenance+xml

Dear Philippe,

This is a reminder that IANA needs your response by 17 April.

Thanks in advance,

Amanda Baber
IANA Request Specialist
ICANN

On Mon Mar 18 21:37:30 2013, amanda.baber wrote:
> Dear Philippe, all,
> 
> 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 17 April) with a revised application.
> 
> If you have any questions, please don't hesitate to contact us.
> 
> Best regards,
> 
> Amanda Baber
> IANA Request Specialist
> ICANN
> 
> ==
> 
> > Name : Philippe Le Hegaret
> 
> > Email : public-media-types@w3.org
> 
> > MIME media type name : Application
> 
> > MIME subtype name : provenance+xml
> 
> > Required parameters : none
> 
> > Optional parameters :
> > Same as charset parameter of application/xml as specified in RFC3023
>    (Section 3.2).
> 
> > Encoding considerations : 7bit
> 
> This would only be correct if the content consisted of nothing but US-
>    ASCII characters. Given it is XML, this is almost certainly not the
>    case. The question is whether or not the content is limited to
>    being epxressed in utf-8 or if utf-16 variants are allowed. If it's
>    the former then this should be 8bit, if the latter binary.
> 
> I also note that this doesn't match the encoding considerations given
>    in http://www.w3.org/TR/prov-xml/.
> 
> > 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.
> 
> This entire section appears to be the security considerations for a
>    different type. It certainly doesn't match what's in
>    http://www.w3.org/TR/prov-xml/for this type.
> 
> What's in http://www.w3.org/TR/prov-xml/ is actually pretty close to
>    what's needed. The one thing that needs to be added is, given that
>    this is an XML-based format, whether or not it's appropriate to use
>    XML signing and/or encryption, as opposed to external protection
>    provided by, say, SSL/TLS, to protect the content. (It's also fine
>    to say both can be used.)
> 
> > Interoperability considerations :
> 
> 
> > Published specification :
> > PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau
>    http://www.w3.org/TR/prov-xml/, 2013.
> 
> > Applications which use this media :
> 
> This doesn't match what's in the document either.
> 
> > Additional information :
> 
> > 1. Magic number(s) : Same as for application/xml [RFC3023]
> 
> Also doesn't match
> 
> > 2. File extension(s) : .provx
> > 3. Macintosh file type code : TEXT
> > 4. Object Identifiers: none
> 
> 
> 
> > Person to contact for further information :
> 
> > 1. Name : Ivan Herman
> > 2. Email : ivan@w3.org
> 
> > Intended usage : Common
> 
> 
> > Author/Change controller : The PROV-XML specification is the product
>    of the World Wide Web Consortium's Provenance Working Group.
> 
> > The W3C, and the W3C Provenance Working Group, have change control
>    over this specification.
>

Received on Wednesday, 27 March 2013 20:24:04 UTC