From nobody Tue Jun 1 15:54:08 2021 Return-Path: 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 44FE03A2A78; Tue, 1 Jun 2021 15:54:06 -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, SPF_HELO_NONE=0.001, SPF_PASS=-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 jnHMMLr-aP3M; Tue, 1 Jun 2021 15:54:02 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBE43A2A7E; Tue, 1 Jun 2021 15:54:01 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FvnX809S1z316C; Wed, 2 Jun 2021 00:53:59 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2407033D-B007-43F7-8401-8FB67CEB87EC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Carsten Bormann In-Reply-To: <3F23A213-36C2-4EC7-B2DF-8CBA690E0438@ietf.org> Date: Wed, 2 Jun 2021 00:53:59 +0200 Cc: Donald Eastlake , tools-discuss@ietf.org Message-Id: <275D7CF9-5569-465D-9652-F24D9A63621E@tzi.org> References: <10C19260-EBAF-41EC-B4FE-BBF23919D84D@tzi.org> <3F23A213-36C2-4EC7-B2DF-8CBA690E0438@ietf.org> To: Jay Daley X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 22:54:06 -0000 --Apple-Mail=_2407033D-B007-43F7-8401-8FB67CEB87EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2. Jun 2021, at 00:34, Jay Daley wrote: >=20 >=20 >=20 >> On 2/06/2021, at 9:59 AM, Carsten Bormann > wrote: >>=20 >> On 2021-06-01, at 21:26, Jay Daley > wrote: >>>=20 >>> So that I=E2=80=99m 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). >>=20 >> Not quite, because the file at one of the URLs might change. >=20 > I see. Some more questions: >=20 > - I=E2=80=99m guessing, though I don=E2=80=99t 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=E2=80=99t (I have local copies of all IETF documents + a local = installation of rfcdiff). I use the web page: =E2=80=94 when I get a new draft mail =E2=80=94 there is a convenient = diff link in there, and I=E2=80=99d need to rsync first otherwise (*). =E2=80=94 to send the URL to other people (via mail, via GitHub = README.md, telegram, =E2=80=A6). > Of course it could switch from a GET to a POST in that situation but I = don=E2=80=99t know what the impact of that is. >=20 > - Would a bookmarkable stored result with a 'refresh' button do the = same thing? I=E2=80=99d 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? =20 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=E2=80=99s favorites=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten (*) which can be slow, because the RFC editor tends to update files that = didn=E2=80=99t change, so rsync needs to check all these files each = time. I don=E2=80=99t know who I need to talk to about how to update a file = offered for rsync (i.e., don=E2=80=99t, unless it changed). --Apple-Mail=_2407033D-B007-43F7-8401-8FB67CEB87EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 2. Jun 2021, at 00:34, Jay Daley <jay@ietf.org> wrote:



On 2/06/2021, at 9:59 AM, Carsten Bormann = <cabo@tzi.org> = wrote:

On 2021-06-01, at 21:26, Jay Daley <jay@ietf.org> wrote:

So that = I=E2=80=99m 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=E2=80=99m guessing, though I don=E2=80=99t 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=E2=80=99t (I have local copies of all IETF documents + a local = installation of rfcdiff).

I use the = web page:

=E2=80=94 when I get a new = draft mail =E2=80=94 there is a convenient diff link in there, and I=E2=80= =99d need to rsync first otherwise (*).
=E2=80=94 to send the = URL to other people (via mail, via GitHub README.md, telegram, = =E2=80=A6).

Of course it could switch from a GET to a POST in that = situation but I don=E2=80=99t know what the impact of that is.

- Would a bookmarkable stored result = with a 'refresh' button do the same thing?

I=E2=80= =99d 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=E2=80=99s = favorites=E2=80=A6

Gr=C3=BC=C3=9F= e, Carsten

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

= --Apple-Mail=_2407033D-B007-43F7-8401-8FB67CEB87EC--