Subject: [media-types] request for comments on media types section of PROV-XML

From: Stephan Zednik <[email-masked]>
Date: Sat, 23 Feb 2013 16:57:09 -0700

link to media type section in editors draft of specification:  https://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html#media-type

Type name:
application

Subtype name:
provenance+xml

Required parameters:
none

Optional parameters:
charset - this parameter may be required when transferring non-ASCII data across some protocols.

Encoding considerations:
The syntax of PROV-XML is expressed over code points in Unicode [[!UNICODE]]

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 <a class="norm" href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized Resource Identifiers (IRIs)</a> [[!RFC3987]] Section 8, as well as <a class="norm" href="http://www.ietf.org/rfc/rfc3986.txt">Uniform Resource Identifier (URI): Generic Syntax</a> [[!RFC3986]] Section 7.  Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic &quot;&#1086;&quot; may appear similar to a Latin &quot;o&quot;). 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 <a class="inform" href="http://www.unicode.org/reports/tr36/">Unicode Security Considerations</a> [[UNISEC]] and <a class="norm" href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized Resource Identifiers (IRIs)</a> [[!RFC3987]] Section 8.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau <a href="http://www.w3.org/TR/prov-xml/">http://www.w3.org/TR/prov-xml/</a>, 2012.

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.

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

	Base URI:
	As in XML.

	Macintosh file type code(s):
	"TEXT"

Person & email address to contact for further information
Ivan Herman, [email-masked]

Intended usage:
COMMON

Restrictions on usage:
None

Author/Change controller:
The PROV-XML specification is the product of the World Wide Web Consortium's Provenance Working Group. The W3C has change control over this specification.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 25 Feb 2013 15:31:00 +0100

* Stephan Zednik wrote:
>link to media type section in editors draft of specification:  
>https://dvcs.w3.org/hg/prov/raw-file/default/xml/prov-xml.html#media-type
>
>Type name:
>application
>
>Subtype name:
>provenance+xml
>
>Required parameters:
>none
>
>Optional parameters:

This should use language as provided in RFC 3023 section 7.1.

>The syntax of PROV-XML is expressed over code points in Unicode [[!UNICODE]]

As above.

>[...]

There are formatting problems here (like use of entity references).

>Published specification:
>PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau <a 
>href="http://www.w3.org/TR/prov-xml/">http://www.w3.org/TR/prov-xml/</a>, 
>2012.

I believe this is still (after the RFC4288 revision) supposed to
reference a specification that actually includes the template, and
the published draft does not include it.

>	PROV-XML documents are XML documents and thus may have initial strings similar to any XML document.

I don't understand what that means; I suggest removing this field.

>The PROV-XML specification is the product of the World Wide Web 
>Consortium's Provenance Working Group. The W3C has change control over 
>this specification.

Per http://tools.ietf.org/html/rfc6838#section-5.6 you should put that
into two separate fields. I also note that you don't have any Fragment
Identifier Considerations.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Stephan Zednik <[email-masked]>
Date: Tue, 26 Feb 2013 00:55:43 -0700

> This should use language as provided in RFC 3023 section 7.1.

Here, and a few areas below such as with "Base URI" I was following the example OWL XML.

from http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type.2C_File_Extension.2C_and_Macintosh_File_Type

Should it be:

"Same as charset parameter of application/xml as specified in RFC 3023 (Section 3.2)."

>> The syntax of PROV-XML is expressed over code points in Unicode [[!UNICODE]]

Should it be:

"Same as encoding considerations of application/xml as specified in RFC 3023 (Section 3.2)."

> There are formatting problems here (like use of entity references).

Is the use of entity references here bad?  Or is there something wrong with them?

Is the content ok?

> the published draft does not include it.

Could you rephrase?  or better yet, provide insight on what should go here.

> I don't understand what that means; I suggest removing this field.

I assume you mean "Base URI" and not all of "Additional Information"?

Here I was following the example from the OWL XML.

Base URI is mentioned in RFC 3023 Section 7.1

"These registrations SHOULD also make reference to RFC 3023 in specifying magic numbers, fragment identifiers, base URIs, and use of the BOM."

> into two separate fields.

Author:
The PROV-XML specification is the product of the World Wide Web Consortium's Provenance Working Group.
Change controller:
The W3C has change control over this specification.

> I also note that you don't have any Fragment

I don't have any beyond what is in RFC 3023 Section 5.

Should I put "none" or "Same as RFC 3023 (Section 5.)."?

--Stephan

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 26 Feb 2013 12:21:45 +0100

>from http://www.w3.org/TR/owl2-xml-serialization/#Appendix:_Internet_Media_Type.2C_File_Extension.2C_and_Macintosh_File_Type

It would be better to follow the example of a registered type. The type
there has not been registered.

>"Same as charset parameter of application/xml as specified in RFC 3023 (Section 3.2)."

Yes.

>"Same as encoding considerations of application/xml as specified in RFC 3023 (Section 3.2)."

Yes.

>Is the use of entity references here bad?  Or is there something wrong with them?

Using them in plain text documents is bad, yes.

>Could you rephrase?  or better yet, provide insight on what should go here.

The issue will go away when your editor's draft is published under the
address given above and the specification reference is updated to refer
to it (it would have to cite "2013" as the year, then).

>I assume you mean "Base URI" and not all of "Additional Information"?

Yes.

>Should I put "none" or "Same as RFC 3023 (Section 5.)."?

A value of "N/A" might be best.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Stephan Zednik <[email-masked]>
Date: Wed, 27 Feb 2013 01:51:17 -0700

Hi Bjoern, how is this?

--Stephan

===================

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.

Published specification:
PROV-XML: The PROV XML Schema, Hua, Tilmes, Zednik (eds), Moreau http://www.w3.org/TR/prov-xml/, 2013.

Fragment identifier considerations:
N/A

Additional Information:

Magic number(s):

File extension(s):
.provx

Person & email address to contact for further information:
Ivan Herman, [email-masked]

Intended usage:
COMMON

Restrictions on usage:
None

Author:

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

===================