Re: [Tools-discuss] Rfcdiff v 0.12 feedback

Jay Daley <> Tue, 01 June 2021 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D3273A0DD9 for <>; Tue, 1 Jun 2021 16:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LLFy4fZpEZQZ; Tue, 1 Jun 2021 16:16:56 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5DDD93A2B2E; Tue, 1 Jun 2021 16:16:55 -0700 (PDT)
From: Jay Daley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA34BDEB-84F9-4AB2-9DE9-9D5042E89761"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 02 Jun 2021 11:16:52 +1200
In-Reply-To: <>
Cc: Tools Discussion <>
To: Carsten Bormann <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Tools-discuss] Rfcdiff v 0.12 feedback
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Jun 2021 23:17:01 -0000

> On 2/06/2021, at 10:53 AM, Carsten Bormann <> wrote:
> On 2. Jun 2021, at 00:34, Jay Daley < <>> wrote:
>>> On 2/06/2021, at 9:59 AM, Carsten Bormann < <>> wrote:
>>> On 2021-06-01, at 21:26, Jay Daley < <>> wrote:
>>>> So that I’m clear - do you want to bookmark the GET in order to repeat the same diff?  In other words, if the result was stored indefinitely and a bookmarkable URL returned then would that be sufficient for you?  (not designing things here, just trying to understand the use case).
>>> Not quite, because the file at one of the URLs might change.
>> I see.  Some more questions:
>> - I’m guessing, though I don’t know, that the reason for a POST is so that a local file can be provided in the form body, which a GET cannot do.  Is that a use case you use? 
> I don’t (I have local copies of all IETF documents + a local installation of rfcdiff).
> I use the web page:
> — when I get a new draft mail — there is a convenient diff link in there, and I’d need to rsync first otherwise (*).
> — to send the URL to other people (via mail, via GitHub, telegram, …).
>> Of course it could switch from a GET to a POST in that situation but I don’t know what the impact of that is.
>> - Would a bookmarkable stored result with a 'refresh' button do the same thing?
> I’d need these other people to press the refresh button.
>> - Is this just a time saver or is there another reason not to use the web form each time?  
> See above.
>> I ask because there are time saving techniques that can be adopted on web forms - 'recent diffs', 'favourites' etc.
> I have no control over other people’s favorites…

Got it - thank you. So

1.  If this functionality was only for files accessible over the web then a GET could be used each time.

2.  If a local file needs to be uploaded then that has to use a POST to send it.  It could possibly redirect to a GET using a stored copy of the uploaded file to provide this functionality

3.  Any storing/caching of the output would probably complicate matters considerably as we then need to take into account versioning, change detection and so on.

Sound about right?

> Grüße, Carsten
> (*) which can be slow, because the RFC editor tends to update files that didn’t change, so rsync needs to check all these files each time.
> I don’t know who I need to talk to about how to update a file offered for rsync (i.e., don’t, unless it changed).

Jay Daley
IETF Executive Director