Fwd: Fwd: [IANA #660606] Request for MIME media type Text/Standards Tree - provenance-notation

Dear all,

Some formal feedback regarding our text/provenance-notation mime type 
application.
It's probably relevant to the xml application.
Thoughts, comments, suggestions welcome!

Luc




-------- Original Message --------
Subject:  Fwd: [IANA #660606] Request for MIME media type Text/Standards 
Tree - provenance-notation
Resent-Date:  Mon, 25 Feb 2013 20:15:27 +0000
Resent-From:  <team-prov-chairs@w3.org>
Date:  Mon, 25 Feb 2013 21:15:02 +0100
From:  Ivan Herman <ivan@w3.org>
To:  W3C Chairs of Prov WG <team-prov-chairs@w3.org>
CC:  Philippe le Hégaret <plh@w3.org>



Luc, Paul,

something for you. Do not seem to be a big deal, small things that may 
be handled quickly I guess.

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)



Begin forwarded message:

> *From:* "Amanda Baber via RT" <iana-mime@iana.org 
> <mailto:iana-mime@iana.org>>
> *Date:* 25 February 2013 21:07:23 CET
> *To:* ivan@w3.org <mailto:ivan@w3.org>, team-media-types@w3.org 
> <mailto:team-media-types@w3.org>
> *Subject:* *[IANA #660606] Request for MIME media type Text/Standards 
> Tree - provenance-notation*
> *Reply-To:* iana-mime@iana.org <mailto:iana-mime@iana.org>
>
> 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 27 March) with a revised Security Considerations section.
>
> 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 : team-media-types@w3.org <mailto:team-media-types@w3.org>
>
>> MIME media type name : Text
>
>> MIME subtype name : Standards Tree - provenance-notation
>
>> Required parameters : charset — the value of charset must always be 
>> UTF-8.
>
>> Optional parameters :
>> None
>
>> Encoding considerations : 8bit
>
>
>> Security considerations :
>
>> PROV-N is a general-purpose language for describing the provenance of 
>> things;
>> applications may evaluate given data to infer more descriptions or 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-N is used to express the provenance of arbitrary application data;
>> security considerations will vary by domain of use. Security tools and
>> protocols applicable to text (e.g. PGP encryption, MD5 sum validation,
>> password-protected compression) may also be used on PROV-N documents.
>> Security/privacy protocols must be imposed which reflect the 
>> sensitivity of the
>> embedded information.
>
>> PROV-N 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-N is a language for describing the provenance of things, and 
>> therefore a
>> PROV-N document is metadata for other resources. Untrusted PROV-N 
>> documents may
>> mislead its consumers by indicating that a third-party resource has a 
>> reputable
>> lineage, when it has not. Provenance of PROV-N document should be sought.
>
>> PROV-N uses qualified names mappable to IRIs as term identifiers.
>> Applications interpreting data expressed in PROV-N 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.
>
> These security considerations are excellent, especially in regards to 
> the coverage of trust issues.
>
> However, there's something I missed the first time I reviwed this: 
> Section 5 talks about extensibiity. It should be noted that extensions 
> may introduce additional security considerations.
>
> I also have a change to suggest (not require). Reading the 
> specification leads me to conclude that the language is entirely 
> descriptive, not directly executable. Generally speaking executable 
> languages may call for the use of sandboxing and other techniques, 
> whereas descriptive languages do not. If I'm correct in this assesment 
> it might be helpful to point it out.
>
>> Interoperability considerations :
>
>
>> Published specification : > PROV-N: The Provenance Notation, Moreau, 
>> Missier,
> (eds), Cheney, Soiland-Reyes http://www.w3.org/TR/prov-n/, 2012.
>
>> Applications which use this media :
>> It may be used by any application for publishing provenance 
>> information. This format is designed to be a human-readable form of 
>> provenance.
>
>> Additional information :
>
>> 1. Magic number(s) : The string "document" near the beginning of the 
>> document.
>> 2. File extension(s) : provn
>> 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-N specification is the product of 
>> the World Wide Web Consortium's Provenance Working Group. The W3C has 
>> change control over this specification.
>
>