Subject: Re: [ietf-types] Mime Type registration (PROV Last Call)
From: "Martin J. Dürst" <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>, [email-masked]
Date: Mon, 30 Jul 2012 11:05:24 +0900
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On 2012/07/27 21:41, Bjoern Hoehrmann wrote:
> * Luc Moreau wrote:
>> Type name:
>> text
>>
>> Subtype name:
>> provenance-notation
>>
>> Required parameters:
>> None
>>
>> Optional parameters:
>> charset — this parameter is mandatory. The value of charset is always UTF-8.
>
> This seems to need work, it's not optional if it is mandatory, is it.
> And The second sentence is a statement of fact that is easily contr-
> dicted by content.
>
>> Encoding considerations:
>> The syntax of PROV-N is expressed over code points in Unicode
>> [UNICODE5]. The encoding is always UTF-8 [UTF-8].
>> Unicode code points may also be expressed using an \uXXXX (U+0 to
>> U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a
>> hexadecimal digit [0-9A-F]

Why [UNICODE5]? The newest version is Unicode 6.2. Is PROV-N limited to 
Unicode version 5? That would be a very bad idea.

Regards,    Martin.

> This field should contain one of the values in RFC 4288 or its successor
> if that has been approved already, like "binary".
>
>> Applications which use this media type:
>> No widely deployed applications are known to use this media type. It may
>> be used by some web services and clients consuming their data.
>
> You can remove the first sentence, this is to give people an idea
> whether this is for Word processing applications or cryptographic
> key exchange systems or whatever.
>
>> Person&  email address to contact for further information:
>> [email-masked]
>
> This does not qualify as "Person&  email address".

Date: Mon, 30 Jul 2012 11:03:53 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Luc Moreau <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Mime Type registration (PROV Last Call)

Hello Luc,

On 2012/07/27 19:19, Luc Moreau wrote:
> Dear all,
>
> The W3C Provenance Working has published a Last Call Working Draft for
> the PROV Notation.
>
> We would be grateful for your feedback on the Media Type section of the
> specification.
>
> 1. Media Type Section: http://www.w3.org/TR/prov-n/#media-type
> 2. Text Version:
> http://dvcs.w3.org/hg/prov/raw-file/default/model/media-type-request.txt

On this list, if possible, always include the actual text of the 
registration template. The chance for feedback is much higher.

Regards,    Martin.

> We look forward to hearing your comments,
>
> Text version is included below, and followed by the last call announcement.
>
> Best regards,
> Luc Moreau
> W3C PROV-WG co-chair
>
> --------------------------------------------------------
>
> The media type of PROV-N is text/provenance-notation. The content
> encoding of PROV-N content is UTF-8.
>
> Contact:
> Ivan Herman
> See also:
> How to Register a Media Type for a W3C Specification
> Internet Media Type registration, consistency of use
> TAG Finding 3 June 2002 (Revised 4 September 2002)
> The Internet Media Type / MIME Type for PROV-N is
> "text/provenance-notation".
>
> It is recommended that PROV-N files have the extension ".provn" (all
> lowercase) on all platforms.
>
> It is recommended that PROV-N files stored on Macintosh HFS file systems
> be given a file type of "TEXT".
>
> This information that follows is being submitted to the IESG for review,
> approval, and registration with IANA.
>
> Type name:
> text
>
> Subtype name:
> provenance-notation
>
> Required parameters:
> None
>
> Optional parameters:
> charset — this parameter is mandatory. The value of charset is always
> UTF-8.
>
> Encoding considerations:
> The syntax of PROV-N is expressed over code points in Unicode
> [UNICODE5]. The encoding is always UTF-8 [UTF-8].
> Unicode code points may also be expressed using an \uXXXX (U+0 to
> U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a
> hexadecimal digit [0-9A-F]
>
> 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 mappeable 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.
> Interoperability considerations:
>
> There are no known interoperability issues.
>
> Published specification:
> PROV-N: The Provenance Notation, Moreau, Missier, (eds), Cheney,
> Soiland-Reyes http://www.w3.org/TR/prov-n/
>
> Applications which use this media type:
> No widely deployed applications are known to use this media type. It may
> be used by some web services and clients consuming their data.
>
> Additional information:
> Magic number(s):
> PROV-N documents may have the strings 'bundle' near the beginning of the
> document.
>
> File extension(s):
> ".provn"
>
> Base URI:
> There are no constructs in the PROV-N Syntax to change the Base IRI.
>
> Macintosh file type code(s):
> "TEXT"
>
> Person & email address to contact for further information:
> [email-masked]
>
> Intended usage:
> COMMON
>
> Restrictions on usage:
> None
>
> Author/Change controller:
> The PROV-N specification is the product of the World Wide Web
> Consortium's PROV Working Group. The W3C has change control over this
> specification.
>
>
> -------- Original Message --------
> Subject: PROV Last Call on three documents: Request for Review
> Resent-Date: Tue, 24 Jul 2012 14:53:27 +0000
> Resent-From: <[email-masked]>
> Date: Tue, 24 Jul 2012 16:52:57 +0200
> From: Paul Groth <[email-masked]>
> To: [email-masked] Chairs <[email-masked]>
> CC: <[email-masked]>
>
>
>
> Dear All,
>
> The Provenance Working has published the following three drafts as
> Last Call Working Drafts:
>
> - PROV-DM: The PROV Data Model [1]
> - PROV-O: The PROV Ontology [2]
> - PROV-N: The Provenance Notation [3]
>
> We are looking for your feedback. To introduce you to the
> specifications, we also have published an updated Primer [4]. You'll
> also find an overview blog post at [5].
>
> The Last Call period ends 18 September 2012. Comments can be sent to
> [email-masked]
>
> We are particularly looking for feedback from the following groups:
>
> - Semantic Web Coordination Group
> - RDFa Working Group
> - RDF Working Group
> - Internationalization Activity
> - MultilingualWeb-LT Working Group
>
> We will follow-up with the chairs of these groups individually
> outlining specific areas where feedback will be useful.
>
> We look forward to hearing your comments.
>
> regards,
> Paul
>
>
> [1] http://www.w3.org/TR/2012/WD-prov-dm-20120724/
> [2] http://www.w3.org/TR/2012/WD-prov-o-20120724/
> [3] http://www.w3.org/TR/2012/WD-prov-n-20120724/
> [4] http://www.w3.org/TR/2012/WD-prov-primer-20120724/
> [5]
> http://www.w3.org/blog/SW/2012/07/24/last-call-3-working-drafts-for-provenance-interchange/
>
>
>
>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Bjoern Hoehrmann <[email-masked]>
To: Luc Moreau <[email-masked]>
Date: Fri, 27 Jul 2012 14:41:33 +0200
Cc: "[email-masked]" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Mime Type registration (PROV Last Call)

* Luc Moreau wrote:
>Type name:
>text
>
>Subtype name:
>provenance-notation
>
>Required parameters:
>None
>
>Optional parameters:
>charset — this parameter is mandatory. The value of charset is always UTF-8.

This seems to need work, it's not optional if it is mandatory, is it.
And The second sentence is a statement of fact that is easily contr-
dicted by content.

>Encoding considerations:
>The syntax of PROV-N is expressed over code points in Unicode 
>[UNICODE5]. The encoding is always UTF-8 [UTF-8].
>Unicode code points may also be expressed using an \uXXXX (U+0 to 
>U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a 
>hexadecimal digit [0-9A-F]

This field should contain one of the values in RFC 4288 or its successor
if that has been approved already, like "binary".

>Applications which use this media type:
>No widely deployed applications are known to use this media type. It may 
>be used by some web services and clients consuming their data.

You can remove the first sentence, this is to give people an idea
whether this is for Word processing applications or cryptographic
key exchange systems or whatever.

>Person & email address to contact for further information:
>[email-masked]

This does not qualify as "Person & email address".
-- 
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/ 

Date: Fri, 27 Jul 2012 11:19:50 +0100
From: Luc Moreau <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>, [email-masked]
Subject: [ietf-types] Mime Type registration (PROV Last Call)

This is a multi-part message in MIME format.
--------------070702060508030300070606
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear all,

The W3C Provenance Working has published a Last Call Working Draft for 
the PROV Notation.

We would be grateful for your feedback on the Media Type section of the 
specification.

1. Media Type Section: http://www.w3.org/TR/prov-n/#media-type
2. Text Version: 
http://dvcs.w3.org/hg/prov/raw-file/default/model/media-type-request.txt

We look forward to hearing your comments,

Text version is included below, and followed by the last call announcement.

Best regards,
Luc Moreau
W3C PROV-WG co-chair

--------------------------------------------------------

The media type of PROV-N is text/provenance-notation. The content 
encoding of PROV-N content is UTF-8.

Contact:
Ivan Herman
See also:
How to Register a Media Type for a W3C Specification
Internet Media Type registration, consistency of use
TAG Finding 3 June 2002 (Revised 4 September 2002)
The Internet Media Type / MIME Type for PROV-N is 
"text/provenance-notation".

It is recommended that PROV-N files have the extension ".provn" (all 
lowercase) on all platforms.

It is recommended that PROV-N files stored on Macintosh HFS file systems 
be given a file type of "TEXT".

This information that follows is being submitted to the IESG for review, 
approval, and registration with IANA.

Type name:
text

Subtype name:
provenance-notation

Required parameters:
None

Optional parameters:
charset — this parameter is mandatory. The value of charset is always UTF-8.

Encoding considerations:
The syntax of PROV-N is expressed over code points in Unicode 
[UNICODE5]. The encoding is always UTF-8 [UTF-8].
Unicode code points may also be expressed using an \uXXXX (U+0 to 
U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a 
hexadecimal digit [0-9A-F]

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 mappeable 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.
Interoperability considerations:

There are no known interoperability issues.

Published specification:
PROV-N: The Provenance Notation, Moreau, Missier, (eds), Cheney, 
Soiland-Reyes http://www.w3.org/TR/prov-n/

Applications which use this media type:
No widely deployed applications are known to use this media type. It may 
be used by some web services and clients consuming their data.

Additional information:
Magic number(s):
PROV-N documents may have the strings 'bundle' near the beginning of the 
document.

File extension(s):
".provn"

Base URI:
There are no constructs in the PROV-N Syntax to change the Base IRI.

Macintosh file type code(s):
"TEXT"

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

Intended usage:
COMMON

Restrictions on usage:
None

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

-------- Original Message --------
Subject: 	PROV Last Call on three documents: Request for Review
Resent-Date: 	Tue, 24 Jul 2012 14:53:27 +0000
Resent-From: 	<[email-masked]>
Date: 	Tue, 24 Jul 2012 16:52:57 +0200
From: 	Paul Groth <[email-masked]>
To: 	[email-masked] Chairs <[email-masked]>
CC: 	<[email-masked]>

Dear All,

The Provenance Working has published the following three drafts as
Last Call Working Drafts:

- PROV-DM: The PROV Data Model [1]
- PROV-O: The PROV Ontology [2]
- PROV-N: The Provenance Notation [3]

We are looking for your feedback. To introduce you to the
specifications, we also have published an updated Primer [4]. You'll
also find an overview blog post at [5].

The Last Call period ends 18 September 2012. Comments can be sent to
[email-masked]

We are particularly looking for feedback from the following groups:

- Semantic Web Coordination Group
- RDFa Working Group
- RDF Working Group
- Internationalization Activity
- MultilingualWeb-LT Working Group

We will follow-up with the chairs of these groups individually
outlining specific areas where feedback will be useful.

We look forward to hearing your comments.

regards,
Paul

[1] http://www.w3.org/TR/2012/WD-prov-dm-20120724/
[2] http://www.w3.org/TR/2012/WD-prov-o-20120724/
[3] http://www.w3.org/TR/2012/WD-prov-n-20120724/
[4] http://www.w3.org/TR/2012/WD-prov-primer-20120724/
[5] http://www.w3.org/blog/SW/2012/07/24/last-call-3-working-drafts-for-provenance-interchange/

-- 
--
Dr. Paul Groth ([email-masked])
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
   Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam

--------------070702060508030300070606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Dear all,<br>
    <br>
    <div class="moz-forward-container">The W3C Provenance Working has
      published a
      Last Call Working Draft for the PROV Notation.<br>
      <br>
      We would be grateful for your feedback on the Media Type section
      of the specification.<br>
      <br>
      1. Media Type Section: <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/prov-n/#media-type">http://www.w3.org/TR/prov-n/#media-type</a><br>
      2. Text Version:
      <a class="moz-txt-link-freetext" href="http://dvcs.w3.org/hg/prov/raw-file/default/model/media-type-request.txt">http://dvcs.w3.org/hg/prov/raw-file/default/model/media-type-request.txt</a><br>
      <br>
      We look forward to hearing your comments,<br>
      <br>
      Text version is included below, and followed by the last call
      announcement.<br>
      <br>
      Best regards,<br>
      Luc Moreau<br>
      W3C PROV-WG co-chair<br>
      <br>
      --------------------------------------------------------<br>
      <br>
      The media type of PROV-N is text/provenance-notation. The content
      encoding of PROV-N content is UTF-8.<br>
      <br>
      Contact:<br>
      Ivan Herman<br>
      See also:<br>
      How to Register a Media Type for a W3C Specification<br>
      Internet Media Type registration, consistency of use<br>
      TAG Finding 3 June 2002 (Revised 4 September 2002)<br>
      The Internet Media Type / MIME Type for PROV-N is
      "text/provenance-notation".<br>
      <br>
      It is recommended that PROV-N files have the extension ".provn"
      (all lowercase) on all platforms.<br>
      <br>
      It is recommended that PROV-N files stored on Macintosh HFS file
      systems be given a file type of "TEXT".<br>
      <br>
      This information that follows is being submitted to the IESG for
      review, approval, and registration with IANA.<br>
      <br>
      Type name:<br>
      text<br>
      <br>
      Subtype name:<br>
      provenance-notation<br>
      <br>
      Required parameters:<br>
      None<br>
      <br>
      Optional parameters:<br>
      charset — this parameter is mandatory. The value of charset is
      always UTF-8.<br>
      <br>
      Encoding considerations:<br>
      The syntax of PROV-N is expressed over code points in Unicode
      [UNICODE5]. The encoding is always UTF-8 [UTF-8].<br>
      Unicode code points may also be expressed using an \uXXXX (U+0 to
      U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a
      hexadecimal digit [0-9A-F]<br>
      <br>
      Security considerations:<br>
      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.<br>
      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.<br>
      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.<br>
      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.<br>
      PROV-N uses qualified names mappeable 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.<br>
      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.<br>
      Interoperability considerations:<br>
      <br>
      There are no known interoperability issues.<br>
      <br>
      Published specification:<br>
      PROV-N: The Provenance Notation, Moreau, Missier, (eds), Cheney,
      Soiland-Reyes <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/prov-n/">http://www.w3.org/TR/prov-n/</a><br>
      <br>
      Applications which use this media type:<br>
      No widely deployed applications are known to use this media type.
      It may be used by some web services and clients consuming their
      data.<br>
      <br>
      Additional information:<br>
      Magic number(s):<br>
      PROV-N documents may have the strings 'bundle' near the beginning
      of the document.<br>
      <br>
      File extension(s):<br>
      ".provn"<br>
      <br>
      Base URI:<br>
      There are no constructs in the PROV-N Syntax to change the Base
      IRI.<br>
      <br>
      Macintosh file type code(s):<br>
      "TEXT"<br>
      <br>
      Person &amp; email address to contact for further information:<br>
      <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      Intended usage:<br>
      COMMON<br>
      <br>
      Restrictions on usage:<br>
      None<br>
      <br>
      Author/Change controller:<br>
      The PROV-N specification is the product of the World Wide Web
      Consortium's PROV Working Group. The W3C has change control over
      this specification.<br>
      <br>
      <br>
      -------- Original Message --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
            </th>
            <td>PROV Last Call on three documents: Request for Review</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Resent-Date:
            </th>
            <td>Tue, 24 Jul 2012 14:53:27 +0000</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Resent-From:
            </th>
            <td><a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
            <td>Tue, 24 Jul 2012 16:52:57 +0200</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
            <td>Paul Groth <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> Chairs <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
            <td><a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>Dear All,

The Provenance Working has published the following three drafts as
Last Call Working Drafts:

- PROV-DM: The PROV Data Model [1]
- PROV-O: The PROV Ontology [2]
- PROV-N: The Provenance Notation [3]

We are looking for your feedback. To introduce you to the
specifications, we also have published an updated Primer [4]. You'll
also find an overview blog post at [5].

The Last Call period ends 18 September 2012. Comments can be sent to
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>

We are particularly looking for feedback from the following groups:

- Semantic Web Coordination Group
- RDFa Working Group
- RDF Working Group
- Internationalization Activity
- MultilingualWeb-LT Working Group

We will follow-up with the chairs of these groups individually
outlining specific areas where feedback will be useful.

We look forward to hearing your comments.

regards,
Paul

[1] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2012/WD-prov-dm-20120724/">http://www.w3.org/TR/2012/WD-prov-dm-20120724/</a>
[2] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2012/WD-prov-o-20120724/">http://www.w3.org/TR/2012/WD-prov-o-20120724/</a>
[3] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2012/WD-prov-n-20120724/">http://www.w3.org/TR/2012/WD-prov-n-20120724/</a>
[4] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2012/WD-prov-primer-20120724/">http://www.w3.org/TR/2012/WD-prov-primer-20120724/</a>
[5] <a class="moz-txt-link-freetext" href="http://www.w3.org/blog/SW/2012/07/24/last-call-3-working-drafts-for-provenance-interchange/">http://www.w3.org/blog/SW/2012/07/24/last-call-3-working-drafts-for-provenance-interchange/</a>

-- 
--
Dr. Paul Groth (<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>)
<a class="moz-txt-link-freetext" href="http://www.few.vu.nl/~pgroth/">http://www.few.vu.nl/~pgroth/</a>
Assistant Professor
- Knowledge Representation &amp; Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam

</pre>
      <br>
      <br>
    </div>
    <br>
  </body>
</html>

--------------070702060508030300070606--

Sender: [email-masked]
Date: Sat, 21 Jul 2012 06:11:25 -0400
From: "Eric Prud'hommeaux" <[email-masked]>
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

--20cf3071c6444a216404c5543cab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jul 21, 2012 8:53 AM, Martin J. D=C3=BCrst <[email-masked]> wrot=
e:
>
> On 2012/07/21 5:49, Jon Moore wrote:
>>
>> On Fri, Jul 20, 2012 at 2:46 PM, Paul Libbrecht<[email-masked]>
 wrote:
>>>
>>> Erm... source charset makes sense to me (this is "the charset of the
patch").
>>> But target charset makes no sense into a media-type... this is "after
applying a patch" which is beyond the scope of a single file.
>>
>>
>> No, the issue is that the patch file could have mixed charsets. If the
>> change is 'convert README from iso-8859-1 to utf-8', then the patch
>> file itself will have two character sets:
>>
>> 1. The lines that begin with '-' or ' ' will be iso-8859-1.
>> 2. The lines that begin with '+' will be utf-8.
>>
>> Since these are incompatible charsets (neither is a superset of the
>> other), we need two charset parameters to describe them, and this
>> patch is not capable of being a text/* document. I'm open to other
>> names besides 'source' and 'target', but I'm not sure how we get
>> around having two of them for this case.
>
>
> Just use application/patch. I don't think current diff programs are able
to deal with character encoding parameters. I don't think people
necessarily need to know the source/target encoding in the above example,
unless something weird happens and they need to debug (in which case,
they'll find out by themselves through trial and error anyway).
>
> I also don't think there is much of a use case for:
> - Originator: Has files in Latin-1, makes a diff in that encoding,
>   sends to receiver.
> - Receiver: Has files in UTF-8, wants to apply patch and wants a
>   conversion from Latin-1 to UTF-8 to happen automatically.

I'm not saying that any conventional tools do this (though it would be nice
for them to grow into this functionality), but as someone who manages
public input on a fair number of docs, I receive a lot of 1252 or 8859
undermining my precious UTF-8 docs. If these are properly labeled, I can
iconv them our pull them into emacs and transcode them before applying
them.i expect that the burgeoning popularity of distributed version control
will accentuate this need as people become more adept at managing diffs.

> So I very much agree with Bj=C3=B6rn here.
>
> Regards,   Martin.
>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

--20cf3071c6444a216404c5543cab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>On Jul 21, 2012 8:53 AM, Martin J. D=C3=BCrst &lt;<a href=3D"mailto:duer=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt; On 2012/07/21 5:49, Jon Moore wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Jul 20, 2012 at 2:46 PM, Paul Libbrecht&lt;<a href=3D"mail=
to:[email-masked]">[email-masked]</a>&gt; =C2=A0wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Erm... source charset makes sense to me (this is &quot;the cha=
rset of the patch&quot;).<br>
&gt;&gt;&gt; But target charset makes no sense into a media-type... this is=
 &quot;after applying a patch&quot; which is beyond the scope of a single f=
ile.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; No, the issue is that the patch file could have mixed charsets. If=
 the<br>
&gt;&gt; change is &#39;convert README from iso-8859-1 to utf-8&#39;, then =
the patch<br>
&gt;&gt; file itself will have two character sets:<br>
&gt;&gt;<br>
&gt;&gt; 1. The lines that begin with &#39;-&#39; or &#39; &#39; will be is=
o-8859-1.<br>
&gt;&gt; 2. The lines that begin with &#39;+&#39; will be utf-8.<br>
&gt;&gt;<br>
&gt;&gt; Since these are incompatible charsets (neither is a superset of th=
e<br>
&gt;&gt; other), we need two charset parameters to describe them, and this<=
br>
&gt;&gt; patch is not capable of being a text/* document. I&#39;m open to o=
ther<br>
&gt;&gt; names besides &#39;source&#39; and &#39;target&#39;, but I&#39;m n=
ot sure how we get<br>
&gt;&gt; around having two of them for this case.<br>
&gt;<br>
&gt;<br>
&gt; Just use application/patch. I don&#39;t think current diff programs ar=
e able to deal with character encoding parameters. I don&#39;t think people=
 necessarily need to know the source/target encoding in the above example, =
unless something weird happens and they need to debug (in which case, they&=
#39;ll find out by themselves through trial and error anyway).<br>

&gt;<br>
&gt; I also don&#39;t think there is much of a use case for:<br>
&gt; - Originator: Has files in Latin-1, makes a diff in that encoding,<br>
&gt; =C2=A0 sends to receiver.<br>
&gt; - Receiver: Has files in UTF-8, wants to apply patch and wants a<br>
&gt; =C2=A0 conversion from Latin-1 to UTF-8 to happen automatically.</p>
<p>I&#39;m not saying that any conventional tools do this (though it would =
be nice for them to grow into this functionality), but as someone who manag=
es public input on a fair number of docs, I receive a lot of 1252 or 8859 u=
ndermining my precious UTF-8 docs. If these are properly labeled, I can ico=
nv them our pull them into emacs and transcode them before applying them.i =
expect that the burgeoning popularity of distributed version control will a=
ccentuate this need as people become more adept at managing diffs.</p>

<p>&gt; So I very much agree with Bj=C3=B6rn here.<br>
&gt;<br>
&gt; Regards, =C2=A0 Martin.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; ietf-types mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/ietf-types">https://w=
ww.ietf.org/mailman/listinfo/ietf-types</a></p>

--20cf3071c6444a216404c5543cab--

Date: Sat, 21 Jul 2012 15:52:09 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Jon Moore <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On 2012/07/21 5:49, Jon Moore wrote:
> On Fri, Jul 20, 2012 at 2:46 PM, Paul Libbrecht<[email-masked]>  wrote:
>> Erm... source charset makes sense to me (this is "the charset of the patch").
>> But target charset makes no sense into a media-type... this is "after applying a patch" which is beyond the scope of a single file.
>
> No, the issue is that the patch file could have mixed charsets. If the
> change is 'convert README from iso-8859-1 to utf-8', then the patch
> file itself will have two character sets:
>
> 1. The lines that begin with '-' or ' ' will be iso-8859-1.
> 2. The lines that begin with '+' will be utf-8.
>
> Since these are incompatible charsets (neither is a superset of the
> other), we need two charset parameters to describe them, and this
> patch is not capable of being a text/* document. I'm open to other
> names besides 'source' and 'target', but I'm not sure how we get
> around having two of them for this case.

Just use application/patch. I don't think current diff programs are able 
to deal with character encoding parameters. I don't think people 
necessarily need to know the source/target encoding in the above 
example, unless something weird happens and they need to debug (in which 
case, they'll find out by themselves through trial and error anyway).

I also don't think there is much of a use case for:
- Originator: Has files in Latin-1, makes a diff in that encoding,
   sends to receiver.
- Receiver: Has files in UTF-8, wants to apply patch and wants a
   conversion from Latin-1 to UTF-8 to happen automatically.

So I very much agree with Björn here.

Regards,   Martin.

From: Paul Libbrecht <[email-masked]>
Date: Fri, 20 Jul 2012 22:55:52 +0200
To: Jon Moore <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

Le 20 juil. 2012 =E0 22:49, Jon Moore a =E9crit :

> On Fri, Jul 20, 2012 at 2:46 PM, Paul Libbrecht <[email-masked]> =
wrote:
>> Erm... source charset makes sense to me (this is "the charset of the =
patch").
>> But target charset makes no sense into a media-type... this is "after =
applying a patch" which is beyond the scope of a single file.
>=20
> No, the issue is that the patch file could have mixed charsets. If the
> change is 'convert README from iso-8859-1 to utf-8', then the patch
> file itself will have two character sets:
>=20
> 1. The lines that begin with '-' or ' ' will be iso-8859-1.
> 2. The lines that begin with '+' will be utf-8.
>=20
> Since these are incompatible charsets (neither is a superset of the
> other), we need two charset parameters to describe them, and this
> patch is not capable of being a text/* document. I'm open to other
> names besides 'source' and 'target', but I'm not sure how we get
> around having two of them for this case.

Thanks Jon,

that clarifies and makes sense.

I still believe you could ignore such a difference and expect the =
patch-application-engine to know the charset of its source and thus the =
normal (single) charset annotations would suffice.

Paul

Date: Fri, 20 Jul 2012 16:49:18 -0400
From: Jon Moore <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On Fri, Jul 20, 2012 at 2:46 PM, Paul Libbrecht <[email-masked]> wrote:
> Erm... source charset makes sense to me (this is "the charset of the patch").
> But target charset makes no sense into a media-type... this is "after applying a patch" which is beyond the scope of a single file.

No, the issue is that the patch file could have mixed charsets. If the
change is 'convert README from iso-8859-1 to utf-8', then the patch
file itself will have two character sets:

1. The lines that begin with '-' or ' ' will be iso-8859-1.
2. The lines that begin with '+' will be utf-8.

Since these are incompatible charsets (neither is a superset of the
other), we need two charset parameters to describe them, and this
patch is not capable of being a text/* document. I'm open to other
names besides 'source' and 'target', but I'm not sure how we get
around having two of them for this case.

Jon
-- 
........
Jon Moore

Sender: [email-masked]
Date: Fri, 20 Jul 2012 15:07:50 -0400
From: "Eric Prud'hommeaux" <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

--20cf307f34bacd241204c5479c85
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jul 20, 2012 8:46 PM, "Paul Libbrecht" <[email-masked]> wrote:
>
> Erm... source charset makes sense to me (this is "the charset of the
patch").
> But target charset makes no sense into a media-type... this is "after
applying a patch" which is beyond the scope of a single file.

Just to be clear, I am quite happy to write off the encoding transformation
use case. My argument was that, even without that use case, we need a
charset. Given that constraint, we may as well use the text tree.

> Paul
>
>
> Le 20 juil. 2012 =C3=A0 17:23, Jon Moore a =C3=A9crit :
>
> > On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud'hommeaux <[email-masked]> wrote=
:
> >> Writing off this use case means I don't need to know the *resulting*
> >> character encoding, but that doesn't mean I don't want to know the
character
> >> encoding of a patch which someone mails me or I encounter on the web.
> >> Presuming that the patch matches the target is unreliable and invites =
a
> >> proliferation of doubly-encoded =C3=85s and buried f'ed up authors' na=
mes
and
> >> math symbols.
> >
> > Yes, I was thinking about this too. I believe for the application/*
> > format, we might want to have two (optional) parameters defaulting to
> > us-ascii, perhaps "source-charset" and "target-charset", as a way to
> > describe the "mixed" character set case (where I'm converting from
> > iso-8859-1 to utf-8, for example). Perhaps "charset" as a shorthand
> > for specifying both when they match. We'll have to document what the
> > precedence is among these options if they are over-specified, but this
> > seems tractable.
> >
> >> If we then say that we need a charset parameters, a naive agent
already has
> >> what it needs to suss out line breaks and render text. I'd rather not
see
> >> two media types with no principled descriminator so I'd like to see
text/
> >> with the usual charset rules.
> >
> > Agreed. If a patch can be represented as a text/* type then it should
> > have a singular charset parameter describing the patch as a whole. The
> > draft I-D(*) I'm working up (https://github.com/jonm/text-diff)
> > already contemplates this.
> >
> > Jon
> >
> > (*) I don't think what I currently have there is a viable RFC
> > candidate, so I haven't formally submitted it as an I-D yet. On the
> > other hand, saying "draft Internet-Draft" begs a certain question, and
> > I don't have enough IETF experience to make the call. Is what's there
> > useful enough to start a conversation like this one (meaning I should
> > go ahead and issue version 00 of the I-D), or should I wait until I
> > think there's something closer to a "release candidate"? Any opinions?
> > ........
> > Jon Moore
> > _______________________________________________
> > ietf-types mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-types
>

--20cf307f34bacd241204c5479c85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><br>
On Jul 20, 2012 8:46 PM, &quot;Paul Libbrecht&quot; &lt;<a href=3D"mailto:p=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt; Erm... source charset makes sense to me (this is &quot;the charset of =
the patch&quot;).<br>
&gt; But target charset makes no sense into a media-type... this is &quot;a=
fter applying a patch&quot; which is beyond the scope of a single file.</p>
<p>Just to be clear, I am quite happy to write off the encoding transformat=
ion use case. My argument was that, even without that use case, we need a c=
harset. Given that constraint, we may as well use the text tree.</p>
<p>&gt; Paul<br>
&gt;<br>
&gt;<br>
&gt; Le 20 juil. 2012 =C3=A0 17:23, Jon Moore a =C3=A9crit :<br>
&gt;<br>
&gt; &gt; On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud&#39;hommeaux &lt;<a hr=
ef=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; &gt;&gt; Writing off this use case means I don&#39;t need to know the =
*resulting*<br>
&gt; &gt;&gt; character encoding, but that doesn&#39;t mean I don&#39;t wan=
t to know the character<br>
&gt; &gt;&gt; encoding of a patch which someone mails me or I encounter on =
the web.<br>
&gt; &gt;&gt; Presuming that the patch matches the target is unreliable and=
 invites a<br>
&gt; &gt;&gt; proliferation of doubly-encoded =C3=85s and buried f&#39;ed u=
p authors&#39; names and<br>
&gt; &gt;&gt; math symbols.<br>
&gt; &gt;<br>
&gt; &gt; Yes, I was thinking about this too. I believe for the application=
/*<br>
&gt; &gt; format, we might want to have two (optional) parameters defaultin=
g to<br>
&gt; &gt; us-ascii, perhaps &quot;source-charset&quot; and &quot;target-cha=
rset&quot;, as a way to<br>
&gt; &gt; describe the &quot;mixed&quot; character set case (where I&#39;m =
converting from<br>
&gt; &gt; iso-8859-1 to utf-8, for example). Perhaps &quot;charset&quot; as=
 a shorthand<br>
&gt; &gt; for specifying both when they match. We&#39;ll have to document w=
hat the<br>
&gt; &gt; precedence is among these options if they are over-specified, but=
 this<br>
&gt; &gt; seems tractable.<br>
&gt; &gt;<br>
&gt; &gt;&gt; If we then say that we need a charset parameters, a naive age=
nt already has<br>
&gt; &gt;&gt; what it needs to suss out line breaks and render text. I&#39;=
d rather not see<br>
&gt; &gt;&gt; two media types with no principled descriminator so I&#39;d l=
ike to see text/<br>
&gt; &gt;&gt; with the usual charset rules.<br>
&gt; &gt;<br>
&gt; &gt; Agreed. If a patch can be represented as a text/* type then it sh=
ould<br>
&gt; &gt; have a singular charset parameter describing the patch as a whole=
. The<br>
&gt; &gt; draft I-D(*) I&#39;m working up (<a href=3D"https://github.com/jo=
nm/text-diff">https://github.com/jonm/text-diff</a>)<br>
&gt; &gt; already contemplates this.<br>
&gt; &gt;<br>
&gt; &gt; Jon<br>
&gt; &gt;<br>
&gt; &gt; (*) I don&#39;t think what I currently have there is a viable RFC=
<br>
&gt; &gt; candidate, so I haven&#39;t formally submitted it as an I-D yet. =
On the<br>
&gt; &gt; other hand, saying &quot;draft Internet-Draft&quot; begs a certai=
n question, and<br>
&gt; &gt; I don&#39;t have enough IETF experience to make the call. Is what=
&#39;s there<br>
&gt; &gt; useful enough to start a conversation like this one (meaning I sh=
ould<br>
&gt; &gt; go ahead and issue version 00 of the I-D), or should I wait until=
 I<br>
&gt; &gt; think there&#39;s something closer to a &quot;release candidate&q=
uot;? Any opinions?<br>
&gt; &gt; ........<br>
&gt; &gt; Jon Moore<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; ietf-types mailing list<br>
&gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br=
>
&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/ietf-types">http=
s://www.ietf.org/mailman/listinfo/ietf-types</a><br>
&gt;<br>
</p>

--20cf307f34bacd241204c5479c85--

From: Paul Libbrecht <[email-masked]>
Date: Fri, 20 Jul 2012 20:46:09 +0200
To: Jon Moore <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

Erm... source charset makes sense to me (this is "the charset of the =
patch").
But target charset makes no sense into a media-type... this is "after =
applying a patch" which is beyond the scope of a single file.

Paul

Le 20 juil. 2012 =E0 17:23, Jon Moore a =E9crit :

> On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud'hommeaux <[email-masked]> =
wrote:
>> Writing off this use case means I don't need to know the *resulting*
>> character encoding, but that doesn't mean I don't want to know the =
character
>> encoding of a patch which someone mails me or I encounter on the web.
>> Presuming that the patch matches the target is unreliable and invites =
a
>> proliferation of doubly-encoded =C5s and buried f'ed up authors' =
names and
>> math symbols.
>=20
> Yes, I was thinking about this too. I believe for the application/*
> format, we might want to have two (optional) parameters defaulting to
> us-ascii, perhaps "source-charset" and "target-charset", as a way to
> describe the "mixed" character set case (where I'm converting from
> iso-8859-1 to utf-8, for example). Perhaps "charset" as a shorthand
> for specifying both when they match. We'll have to document what the
> precedence is among these options if they are over-specified, but this
> seems tractable.
>=20
>> If we then say that we need a charset parameters, a naive agent =
already has
>> what it needs to suss out line breaks and render text. I'd rather not =
see
>> two media types with no principled descriminator so I'd like to see =
text/
>> with the usual charset rules.
>=20
> Agreed. If a patch can be represented as a text/* type then it should
> have a singular charset parameter describing the patch as a whole. The
> draft I-D(*) I'm working up (https://github.com/jonm/text-diff)
> already contemplates this.
>=20
> Jon
>=20
> (*) I don't think what I currently have there is a viable RFC
> candidate, so I haven't formally submitted it as an I-D yet. On the
> other hand, saying "draft Internet-Draft" begs a certain question, and
> I don't have enough IETF experience to make the call. Is what's there
> useful enough to start a conversation like this one (meaning I should
> go ahead and issue version 00 of the I-D), or should I wait until I
> think there's something closer to a "release candidate"? Any opinions?
> ........
> Jon Moore
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Fri, 20 Jul 2012 11:23:30 -0400
From: Jon Moore <[email-masked]>
To: "Eric Prud'hommeaux" <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud'hommeaux <[email-masked]> wrote:
> Writing off this use case means I don't need to know the *resulting*
> character encoding, but that doesn't mean I don't want to know the charac=
ter
> encoding of a patch which someone mails me or I encounter on the web.
> Presuming that the patch matches the target is unreliable and invites a
> proliferation of doubly-encoded =C5s and buried f'ed up authors' names an=
d
> math symbols.

Yes, I was thinking about this too. I believe for the application/*
format, we might want to have two (optional) parameters defaulting to
us-ascii, perhaps "source-charset" and "target-charset", as a way to
describe the "mixed" character set case (where I'm converting from
iso-8859-1 to utf-8, for example). Perhaps "charset" as a shorthand
for specifying both when they match. We'll have to document what the
precedence is among these options if they are over-specified, but this
seems tractable.

> If we then say that we need a charset parameters, a naive agent already h=
as
> what it needs to suss out line breaks and render text. I'd rather not see
> two media types with no principled descriminator so I'd like to see text/
> with the usual charset rules.

Agreed. If a patch can be represented as a text/* type then it should
have a singular charset parameter describing the patch as a whole. The
draft I-D(*) I'm working up (https://github.com/jonm/text-diff)
already contemplates this.

Jon

(*) I don't think what I currently have there is a viable RFC
candidate, so I haven't formally submitted it as an I-D yet. On the
other hand, saying "draft Internet-Draft" begs a certain question, and
I don't have enough IETF experience to make the call. Is what's there
useful enough to start a conversation like this one (meaning I should
go ahead and issue version 00 of the I-D), or should I wait until I
think there's something closer to a "release candidate"? Any opinions?
........
Jon Moore

Sender: [email-masked]
Date: Fri, 20 Jul 2012 09:40:01 -0400
From: "Eric Prud'hommeaux" <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: Julian Reschke <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

--14dae9cdc47f78278f04c54308ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jul 20, 2012 2:13 PM, "Bjoern Hoehrmann" <[email-masked]> wrote:
>
> * Julian Reschke wrote:
> >So do you believe we need a variant that is encoding-agnostics except
> >for CRLF detection?
>
> Certainly. An "encoding-aware" variant seems much less necessary.

Writing off this use case means I don't need to know the *resulting*
character encoding, but that doesn't mean I don't want to know the
character encoding of a patch which someone mails me or I encounter on the
web. Presuming that the patch matches the target is unreliable and invites
a proliferation of doubly-encoded =C3=85s and buried f'ed up authors' names=
 and
math symbols.

If we then say that we need a charset parameters, a naive agent already has
what it needs to suss out line breaks and render text. I'd rather not see
two media types with no principled descriminator so I'd like to see text/
with the usual charset rules.

> --
> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:[email-masked] =C2=B7 http://=
bjoern.hoehrmann.de
> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern=
sworld.de
> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w=
ebsitedev.de/
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

--14dae9cdc47f78278f04c54308ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>On Jul 20, 2012 2:13 PM, &quot;Bjoern Hoehrmann&quot; &lt;<a href=3D"mai=
lto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt; * Julian Reschke wrote:<br>
&gt; &gt;So do you believe we need a variant that is encoding-agnostics exc=
ept<br>
&gt; &gt;for CRLF detection?<br>
&gt;<br>
&gt; Certainly. An &quot;encoding-aware&quot; variant seems much less neces=
sary.</p>
<p>Writing off this use case means I don&#39;t need to know the *resulting*=
 character encoding, but that doesn&#39;t mean I don&#39;t want to know the=
 character encoding of a patch which someone mails me or I encounter on the=
 web. Presuming that the patch matches the target is unreliable and invites=
 a proliferation of doubly-encoded =C3=85s and buried f&#39;ed up authors&#=
39; names and math symbols.</p>

<p>If we then say that we need a charset parameters, a naive agent already =
has what it needs to suss out line breaks and render text. I&#39;d rather n=
ot see two media types with no principled descriminator so I&#39;d like to =
see text/ with the usual charset rules.</p>

<p>&gt; --<br>
&gt; Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:<a href=3D"mailto:bjoern@hoehrm=
ann.de">[email-masked]</a> =C2=B7 <a href=3D"http://bjoern.hoehrmann.d=
e">http://bjoern.hoehrmann.de</a><br>
&gt; Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 <a href=3D"htt=
p://www.bjoernsworld.de">http://www.bjoernsworld.de</a><br>
&gt; 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 <a href=
=3D"http://www.websitedev.de/">http://www.websitedev.de/</a><br>
&gt; _______________________________________________<br>
&gt; ietf-types mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/ietf-types">https://w=
ww.ietf.org/mailman/listinfo/ietf-types</a><br>
</p>

--14dae9cdc47f78278f04c54308ed--

From: Bjoern Hoehrmann <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Fri, 20 Jul 2012 14:13:01 +0200
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

* Julian Reschke wrote:
>So do you believe we need a variant that is encoding-agnostics except 
>for CRLF detection?

Certainly. An "encoding-aware" variant seems much less necessary.
-- 
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/ 

Date: Fri, 20 Jul 2012 13:48:41 +0200
From: Julian Reschke <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On 2012-07-20 13:22, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> On 2012-07-20 12:38, Simon Josefsson wrote:
>>> * It can deal with diff's of files with different character sets,
>>>     e.g. converting ISO-8859-1 files to UTF-8.  Like the draft says now,
>>>     the text/* approach is unable to deal with this.
>>
>> I don't see that the problem is.
>>
>>  From a media type of view, the patch consists on instructions how to
>> patch certain lines in a text file. So to make this work properly, the
>> encoding of both the patch and the file-to-be-patched need to be known,
>> but they don't need to be the same.
>
> So, if you have a patch file that turns a ISO-8859-1 encoded file into
> a UTF-8 encoded file, what would be "the encoding" of the patch file?

Always these trick questions :-)

So do you believe we need a variant that is encoding-agnostics except 
for CRLF detection?

Best regards, Julian

From: Bjoern Hoehrmann <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Fri, 20 Jul 2012 13:22:48 +0200
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

* Julian Reschke wrote:
>On 2012-07-20 12:38, Simon Josefsson wrote:
>> * It can deal with diff's of files with different character sets,
>>    e.g. converting ISO-8859-1 files to UTF-8.  Like the draft says now,
>>    the text/* approach is unable to deal with this.
>
>I don't see that the problem is.
>
> From a media type of view, the patch consists on instructions how to 
>patch certain lines in a text file. So to make this work properly, the 
>encoding of both the patch and the file-to-be-patched need to be known, 
>but they don't need to be the same.

So, if you have a patch file that turns a ISO-8859-1 encoded file into
a UTF-8 encoded file, what would be "the encoding" of the patch file?
-- 
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/ 

Date: Fri, 20 Jul 2012 13:17:10 +0200
From: Julian Reschke <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On 2012-07-20 12:38, Simon Josefsson wrote:
> ...
> Some reasons that I had in mind were:
>
> * There is no character set issues -- the encoder doesn't need to know
>    which character encoding was used.  The specification doesn't have to
>    talk about character sets (which makes up a big chunk of the current
>    spec.)
> ...

The encoder needs to be aware of lines, which implies that it knows that 
octet sequence(s) are line endings.

> * It can deal with diff's of files with different character sets,
>    e.g. converting ISO-8859-1 files to UTF-8.  Like the draft says now,
>    the text/* approach is unable to deal with this.

I don't see that the problem is.

 From a media type of view, the patch consists on instructions how to 
patch certain lines in a text file. So to make this work properly, the 
encoding of both the patch and the file-to-be-patched need to be known, 
but they don't need to be the same.

> * Sometimes text/* parts are modified by gateways, and this is usually
>    avoided by using an application/* type.  So the spec doesn't have to
>    talk about these concerns.

If a gateway every changed the charset, it would need to do it properly. 
Otherwise it's broken anyway (and I would be surprised if it handled 
PATCH properly).

> However I support doing both media types.  For some situations,
> text/patch is appropriate.
>
> /Simon

Best regards, Julian

From: Simon Josefsson <[email-masked]>
To: Julian Reschke <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 20 Jul 2012 12:38:14 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

Julian Reschke <[email-masked]> writes:

> On 2012-07-19 14:12, Simon Josefsson wrote:
>> Jon Moore <[email-masked]> writes:
>>
>>> Hi folks,
>>>
>>> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
>>> registering a media type for the output of the 'diff' utility would be
>>> a good idea. I found this thread from 2007 where Julian Reschke
>>> proposed this exact thing:
>>>
>>> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>>>
>>> Does anyone know where this landed? I'd like to pick up the torch and
>>> at least work on text/diff (using the unified diff format, and limited
>>> to those diffs that can be rendered as valid text/* types). I've
>>> started putting together an Internet Draft for it, but was wondering
>>> if this had actually run into technical trouble, or if it just ran out
>>> of steam in 2007.
>>
>> The issue of how to deal with different character encodings were
>> unresolved, and I think it is important to get right.  The approach to
>> specify an application/patch is the easy way out.  Trying to resolve it
>> for a text/patch may be possible, but I fear it will be problematic in
>> practice.  Thus I lean towards a application/patch.
>
> Could you elaborate of what exactly you think would be easier to
> specify using application/patch instead of text/patch?

Some reasons that I had in mind were:

* There is no character set issues -- the encoder doesn't need to know
  which character encoding was used.  The specification doesn't have to
  talk about character sets (which makes up a big chunk of the current
  spec.)

* It can deal with diff's of files with different character sets,
  e.g. converting ISO-8859-1 files to UTF-8.  Like the draft says now,
  the text/* approach is unable to deal with this.

* Sometimes text/* parts are modified by gateways, and this is usually
  avoided by using an application/* type.  So the spec doesn't have to
  talk about these concerns.

However I support doing both media types.  For some situations,
text/patch is appropriate.

/Simon

Date: Thu, 19 Jul 2012 22:27:01 +0200
From: Julian Reschke <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On 2012-07-19 14:12, Simon Josefsson wrote:
> Jon Moore <[email-masked]> writes:
>
>> Hi folks,
>>
>> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
>> registering a media type for the output of the 'diff' utility would be
>> a good idea. I found this thread from 2007 where Julian Reschke
>> proposed this exact thing:
>>
>> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>>
>> Does anyone know where this landed? I'd like to pick up the torch and
>> at least work on text/diff (using the unified diff format, and limited
>> to those diffs that can be rendered as valid text/* types). I've
>> started putting together an Internet Draft for it, but was wondering
>> if this had actually run into technical trouble, or if it just ran out
>> of steam in 2007.
>
> The issue of how to deal with different character encodings were
> unresolved, and I think it is important to get right.  The approach to
> specify an application/patch is the easy way out.  Trying to resolve it
> for a text/patch may be possible, but I fear it will be problematic in
> practice.  Thus I lean towards a application/patch.

Could you elaborate of what exactly you think would be easier to specify 
using application/patch instead of text/patch?

Best regards, Julian

Date: Thu, 19 Jul 2012 12:14:50 -0700
From: Steve Allen <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

> From: Jon Moore <[email-masked]>
> Date: Thu, 19 Jul 2012 09:24:15 -0400
> Subject: Re: [ietf-types] Status of application/patch or text/patch?

> Does anyone have opinions regarding whether this should be one or two RFCs?

RFC 4047 gives precedent for describing multiple MIME media types.

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From: Simon Josefsson <[email-masked]>
To: Jon Moore <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 19 Jul 2012 15:39:36 +0200
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Status of application/patch or text/patch?

Jon Moore <[email-masked]> writes:

> I think application/{diff,patch} and text/{diff,patch} both have their
> places. The application/* version will be easier to specify, for
> sure. However, a very, very common use case for diff is exchanging
> source code diffs against ASCII-encoded files; being able to have a
> text/* version means, for example, that many clients will be able to
> treat them as generic text files--for example, a browser could just
> display the diff rather than downloading it. So the text/* version
> might be more generally consumable.
>
> There are probably some very simple rules by which a producer could
> run 'diff' and know that the output could be labelled 'text/diff'
> without much extra work (for example, if the two documents given as
> arguments to diff have the same encoding, and it is one of us-ascii,
> iso-8859-*, or utf-8,then you're good).

Agreed.

> My intent would be to document both media types. Does anyone have opinions regarding whether this should be one or two RFCs?

I would prefer one document, for easier review and less text
duplication.

/Simon

From: Jon Moore <[email-masked]>
Date: Thu, 19 Jul 2012 09:24:15 -0400
To: Simon Josefsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Status of application/patch or text/patch?

I think application/{diff,patch} and text/{diff,patch} both have their place=
s. The application/* version will be easier to specify, for sure. However, a=
 very, very common use case for diff is exchanging source code diffs against=
 ASCII-encoded files; being able to have a text/* version means, for example=
, that many clients will be able to treat them as generic text files--for ex=
ample, a browser could just display the diff rather than downloading it. So t=
he text/* version might be more generally consumable.=20

There are probably some very simple rules by which a producer could run 'dif=
f' and know that the output could be labelled 'text/diff' without much extra=
 work (for example, if the two documents given as arguments to diff have the=
 same encoding, and it is one of us-ascii, iso-8859-*, or utf-8,then you're g=
ood).=20

My intent would be to document both media types. Does anyone have opinions r=
egarding whether this should be one or two RFCs?

Jon
........
Jon Moore

On Jul 19, 2012, at 8:12 AM, Simon Josefsson <[email-masked]> wrote:

> Jon Moore <[email-masked]> writes:
>=20
>> Hi folks,
>>=20
>> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
>> registering a media type for the output of the 'diff' utility would be
>> a good idea. I found this thread from 2007 where Julian Reschke
>> proposed this exact thing:
>>=20
>> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>>=20
>> Does anyone know where this landed? I'd like to pick up the torch and
>> at least work on text/diff (using the unified diff format, and limited
>> to those diffs that can be rendered as valid text/* types). I've
>> started putting together an Internet Draft for it, but was wondering
>> if this had actually run into technical trouble, or if it just ran out
>> of steam in 2007.
>=20
> The issue of how to deal with different character encodings were
> unresolved, and I think it is important to get right.  The approach to
> specify an application/patch is the easy way out.  Trying to resolve it
> for a text/patch may be possible, but I fear it will be problematic in
> practice.  Thus I lean towards a application/patch.
>=20
> /Simon

From: Simon Josefsson <[email-masked]>
To: Jon Moore <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 19 Jul 2012 14:12:46 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

Jon Moore <[email-masked]> writes:

> Hi folks,
>
> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
> registering a media type for the output of the 'diff' utility would be
> a good idea. I found this thread from 2007 where Julian Reschke
> proposed this exact thing:
>
> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>
> Does anyone know where this landed? I'd like to pick up the torch and
> at least work on text/diff (using the unified diff format, and limited
> to those diffs that can be rendered as valid text/* types). I've
> started putting together an Internet Draft for it, but was wondering
> if this had actually run into technical trouble, or if it just ran out
> of steam in 2007.

The issue of how to deal with different character encodings were
unresolved, and I think it is important to get right.  The approach to
specify an application/patch is the easy way out.  Trying to resolve it
for a text/patch may be possible, but I fear it will be problematic in
practice.  Thus I lean towards a application/patch.

/Simon

From: Jon Moore <[email-masked]>
Date: Wed, 11 Jul 2012 05:02:26 -0400
To: Julian Reschke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Status of application/patch or text/patch?

Well, 2+ years is pretty recent in IETF time. :)

Thanks for the guidance, I'll follow up with APPSAWG.=20

Jon
........
Jon Moore

On Jul 11, 2012, at 3:24 AM, Julian Reschke <[email-masked]> wrote:

> On 2012-07-11 03:12, Jon Moore wrote:
>> Hi folks,
>>=20
>> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
>=20
> 2+ years :-)
>=20
>> registering a media type for the output of the 'diff' utility would be
>> a good idea. I found this thread from 2007 where Julian Reschke
>> proposed this exact thing:
>>=20
>> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>>=20
>> Does anyone know where this landed? I'd like to pick up the torch and
>=20
> Nowhere, as far as I can tell.
>=20
>> at least work on text/diff (using the unified diff format, and limited
>> to those diffs that can be rendered as valid text/* types). I've
>> started putting together an Internet Draft for it, but was wondering
>> if this had actually run into technical trouble, or if it just ran out
>> of steam in 2007.
>>=20
>> Any guidance would be appreciated!
>=20
> My recollection is that I got lost in the output format variations and pot=
ential copyrights.
>=20
> So please go ahead; the IETF APPSAWG mailing list probably is a good place=
 to get feedback.
>=20
> Best regards, Julian

Date: Wed, 11 Jul 2012 09:24:57 +0200
From: Julian Reschke <[email-masked]>
To: Jon Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Status of application/patch or text/patch?

On 2012-07-11 03:12, Jon Moore wrote:
> Hi folks,
>
> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like

2+ years :-)

> registering a media type for the output of the 'diff' utility would be
> a good idea. I found this thread from 2007 where Julian Reschke
> proposed this exact thing:
>
> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>
> Does anyone know where this landed? I'd like to pick up the torch and

Nowhere, as far as I can tell.

> at least work on text/diff (using the unified diff format, and limited
> to those diffs that can be rendered as valid text/* types). I've
> started putting together an Internet Draft for it, but was wondering
> if this had actually run into technical trouble, or if it just ran out
> of steam in 2007.
>
> Any guidance would be appreciated!

My recollection is that I got lost in the output format variations and 
potential copyrights.

So please go ahead; the IETF APPSAWG mailing list probably is a good 
place to get feedback.

Best regards, Julian

Date: Tue, 10 Jul 2012 21:12:22 -0400
From: Jon Moore <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Status of application/patch or text/patch?

Hi folks,

Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
registering a media type for the output of the 'diff' utility would be
a good idea. I found this thread from 2007 where Julian Reschke
proposed this exact thing:

http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html

Does anyone know where this landed? I'd like to pick up the torch and
at least work on text/diff (using the unified diff format, and limited
to those diffs that can be rendered as valid text/* types). I've
started putting together an Internet Draft for it, but was wondering
if this had actually run into technical trouble, or if it just ran out
of steam in 2007.

Any guidance would be appreciated!

Thanks,
Jon
--
........
Jon Moore