Re: [Tools-discuss] Rfcdiff v 0.12 feedback

Jay Daley <jay@ietf.org> Tue, 01 June 2021 23:17 UTC

Return-Path: <jay@ietf.org>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3273A0DD9 for <tools-discuss@ietfa.amsl.com>; Tue, 1 Jun 2021 16:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLFy4fZpEZQZ; Tue, 1 Jun 2021 16:16:56 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 5DDD93A2B2E; Tue, 1 Jun 2021 16:16:55 -0700 (PDT)
From: Jay Daley <jay@ietf.org>
Message-Id: <CDB8F36D-41CA-48F4-BD01-ABA4C3D1D375@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA34BDEB-84F9-4AB2-9DE9-9D5042E89761"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 2 Jun 2021 11:16:52 +1200
In-Reply-To: <275D7CF9-5569-465D-9652-F24D9A63621E@tzi.org>
Cc: Tools Discussion <tools-discuss@ietf.org>
To: Carsten Bormann <cabo@tzi.org>
References: <CAF4+nEGM5Q5sq5Tn5xtPi9FvSyy2cMYC+bZxp2y9bkT39ttheA@mail.gmail.com> <10C19260-EBAF-41EC-B4FE-BBF23919D84D@tzi.org> <B947FB94-9C85-46BF-B77D-53110DC85689@ietf.org> <B26A3FCC-6204-4819-8B70-9668A9384D04@tzi.org> <3F23A213-36C2-4EC7-B2DF-8CBA690E0438@ietf.org> <275D7CF9-5569-465D-9652-F24D9A63621E@tzi.org>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/owdiSZ6WbliCGYBP8F-k-XmO45U>
Subject: Re: [Tools-discuss] Rfcdiff v 0.12 feedback
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 23:17:01 -0000


> On 2/06/2021, at 10:53 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On 2. Jun 2021, at 00:34, Jay Daley <jay@ietf.org <mailto:jay@ietf.org>> wrote:
>> 
>> 
>> 
>>> On 2/06/2021, at 9:59 AM, Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
>>> 
>>> On 2021-06-01, at 21:26, Jay Daley <jay@ietf.org <mailto:jay@ietf.org>> 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 README.md, 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?

Jay
> 
> 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
jay@ietf.org