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

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.

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.

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

On Feb 26, 2013, at 4:21 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Stephan Zednik wrote:
>> On Feb 25, 2013, at 7:31 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>> * Stephan Zednik wrote:
>>>> Optional parameters:
>>>> charset - this parameter may be required when transferring non-ASCII data across some protocols.
>>> 
>>> 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
> 
> It would be better to follow the example of a registered type. The type
> there has not been registered.
> 
>> Should it be:
>> 
>> "Same as charset parameter of application/xml as specified in RFC 3023 (Section 3.2)."
> 
> Yes.
> 
>>>> Encoding considerations:
>>>> The syntax of PROV-XML is expressed over code points in Unicode [[!UNICODE]]
>>> 
>>> As above.
>> 
>> Should it be:
>> 
>> "Same as encoding considerations of application/xml as specified in RFC 3023 (Section 3.2)."
> 
> Yes.
> 
>>>> Security considerations:
>>>> [...]
>>> 
>>> 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?
> 
> Using them in plain text documents is bad, yes.
> 
>>>> 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.
>> 
>> 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).
> 
>>>> 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.
>>> 
>>> I don't understand what that means; I suggest removing this field.
>> 
>> I assume you mean "Base URI" and not all of "Additional Information"?
> 
> Yes.
> 
>>> I also note that you don't have any Fragment
>>> Identifier Considerations.
>> 
>> I don't have any beyond what is in RFC 3023 Section 5.
>> 
>> Should I put "none" or "Same as RFC 3023 (Section 5.)."?
> 
> A value of "N/A" might be best.
> -- 
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · 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/ 
> 
>

Received on Wednesday, 27 February 2013 08:51:50 UTC