Re: [ietf-types] Status of application/patch or text/patch?

Jon Moore <> Thu, 19 July 2012 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 682D421F8606 for <>; Thu, 19 Jul 2012 06:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0fk+zsEh2dLM for <>; Thu, 19 Jul 2012 06:23:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB70521F8672 for <>; Thu, 19 Jul 2012 06:23:31 -0700 (PDT)
Received: by qcsg15 with SMTP id g15so2175524qcs.27 for <>; Thu, 19 Jul 2012 06:24:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=8vJYzgt7Qru7MsQ7aJr8PGuGAGZ6EjbFUOmkO8Ktzws=; b=j9vndMiub1TCr0K+1lsEaKHL5eOvLnni9kwQLI0AwPRMJ0aIxN2u0ac57rDq/2wt6U 8iWtNlfBPUCmiVOjXEGHNkv4mzHMCNtwijSd2XiraxZyAa+hD7zb9ubdjRIIrbhBXrea G3aDvnoWgrbzaOxpn565lqxbQV85D1OUptdqrBPOTAnqcimM5SmVh/QjD8YAhqe2I0So nwca2CFG88BhFhfLurWQYY4JQHpmXp4oEk44em37A4+l5I/weiyAooy5NOxvDfWJSoKB tb0Y7S8Ff4R0UE1bjcaa4FUoZBbmWEoDZIbEMAG4/igoSn0Qzbt3kR1TX0M8U0Q8C6Om Asxw==
Received: by with SMTP id dm10mr3626373qab.94.1342704264550; Thu, 19 Jul 2012 06:24:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id f14sm3067033qak.20.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 06:24:23 -0700 (PDT)
References: <> <>
In-Reply-To: <>
Mime-Version: 1.0 (iPhone Mail 8J2)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPhone Mail (8J2)
From: Jon Moore <>
Date: Thu, 19 Jul 2012 09:24:15 -0400
To: Simon Josefsson <>
X-Gm-Message-State: ALoCoQnH9eLCjkkcOoOf5pSYS8Ekw8KR9mV6ruZODcpCqVDS3sP9nXvR1iw1sPlNPe156OITXgM4
Cc: "" <>
Subject: Re: [ietf-types] Status of application/patch or text/patch?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jul 2012 13:23:32 -0000

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). 

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

Jon Moore

On Jul 19, 2012, at 8:12 AM, Simon Josefsson <> wrote:

> Jon Moore <> 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:
>> 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