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

Dear Amanda,

it seems that something went wrong somewhere. The comments below seem to refer to a older version of the submission; the latest somehow did not make it. 

To make things clear, here is the up-to-date submission. Could you process it? Thank you very much

[[[
Type name:
application

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:
Same as encoding considerations of application/xml as specified in RFC 3023 (Section 3.2).

Security considerations:
PROV-XML is an XML language for describing the provenance of things; applications may evaluate given data to dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data.
PROV-XML can express data which is presented to the user, for example, by means of label attributes. Application rendering strings retrieved from untrusted PROV-N documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup.

PROV-XML is a language for describing the provenance of things, and therefore a PROV-XML document is metadata for other resources. Untrusted PROV-XML documents may mislead its consumers by indicating that a third-party resource has a reputable lineage, when it has not. Provenance of PROV-XML document should be sought.

PROV-XML uses QNames mappable to IRIs as term identifiers. Applications interpreting data expressed in PROV-XML should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7.

Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "ะพ" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in PROV-N must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.

Interoperability considerations:
There are no known interoperability issues.

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 type:
It may be used by any application for publishing provenance information. This format is designed to be an XML form of provenance.

Fragment identifier considerations:
N/A

Additional Information:

Magic number(s):
PROV-XML documents are XML documents and thus may have initial strings similar to any XML document.

File extension(s):
.provx

Macintosh file type code(s):
"TEXT"

Person & email address to contact for further information:
Ivan Herman, ivan@w3.org

Intended usage:
COMMON

Restrictions on usage:
None

Author:
The PROV-XML specification is the product of the World Wide Web Consortium's Provenance Working Group.

Change controller:
The W3C, and the W3C Provenance Working Group, have change control over this specification.
]]]


Thank you!

Ivan Herman



> 
> From: "Amanda Baber via RT" <iana-mime@iana.org<mailto:iana-mime@iana.org>>
> Date: 27 March 2013 21:23:31 CET
> Cc: ivan@w3.org<mailto:ivan@w3.org>, plh@w3.org<mailto:plh@w3.org>, plh@w3.org<mailto:plh@w3.org>, ivan@w3.org<mailto:ivan@w3.org>
> Subject: [IANA #666222] Request for MIME media type Application/Standards Tree - provenance+xml
> Reply-To: iana-mime@iana.org<mailto:iana-mime@iana.org>
> 
> 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<mailto: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<mailto: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.
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Friday, 29 March 2013 12:10:04 UTC