Re: [Ietf-and-github] [rfc-i] New Version Notification for draft-kwatsen-git-xiax-automation-00.txt

Henrik Levkowetz <henrik@levkowetz.com> Tue, 26 February 2019 20:12 UTC

Return-Path: <henrik@levkowetz.com>
X-Original-To: ietf-and-github@ietfa.amsl.com
Delivered-To: ietf-and-github@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CA3124B0C for <ietf-and-github@ietfa.amsl.com>; Tue, 26 Feb 2019 12:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0ReB9EDwrYPO for <ietf-and-github@ietfa.amsl.com>; Tue, 26 Feb 2019 12:12:28 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABFB1288BD for <ietf-and-github@ietf.org>; Tue, 26 Feb 2019 12:12:28 -0800 (PST)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:50791 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1gyj5W-0003Pd-LC; Tue, 26 Feb 2019 12:12:27 -0800
To: Kent Watsen <kent+ietf@watsen.net>
References: <155112114000.10633.2593235416875795961.idtracker@ietfa.amsl.com> <01000169261421c7-978ecbf5-dcc4-4738-ba58-f409ce6adaf1-000000@email.amazonses.com> <0100016926dbd0be-1c4219e8-5389-433c-9326-c17addd023c6-000000@email.amazonses.com> <05d6799b-b4ee-9f04-e77e-dd4f8ea4e3aa@levkowetz.com> <010001692afbb77c-4e1fe666-0631-48e5-aa44-54e477da77d2-000000@email.amazonses.com> <add6a423-7c4a-61b6-bef3-0f36bfac82cd@levkowetz.com> <010001692b5900b0-a1d0677a-0979-421e-b4c1-c054cdbfbab8-000000@email.amazonses.com>
Cc: RFC Interest <rfc-interest@rfc-editor.org>, ietf-and-github@ietf.org
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <08109861-0940-476d-7567-88c6f6b6939f@levkowetz.com>
Date: Tue, 26 Feb 2019 21:12:18 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <010001692b5900b0-a1d0677a-0979-421e-b4c1-c054cdbfbab8-000000@email.amazonses.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="4nDgBVttUETNLR8LdOBWM9OKdFlLBcGJ9"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: ietf-and-github@ietf.org, rfc-interest@rfc-editor.org, kent+ietf@watsen.net
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-and-github/YziohiBvTXYf4fjqxBVTjy4jbuc>
Subject: Re: [Ietf-and-github] [rfc-i] New Version Notification for draft-kwatsen-git-xiax-automation-00.txt
X-BeenThere: ietf-and-github@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of using GitHub in IETF activities, particularly for Working Groups" <ietf-and-github.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-and-github>, <mailto:ietf-and-github-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-and-github/>
List-Post: <mailto:ietf-and-github@ietf.org>
List-Help: <mailto:ietf-and-github-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-and-github>, <mailto:ietf-and-github-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 20:12:31 -0000

Hi Kent,

On 2019-02-26 20:47, Kent Watsen wrote:
> Hi Henrik,
> 
> Just responding to your comment about the "name" attribute (all your
> other comments were on the level).
> 
> While RFC 7991's description of the "name" attribute is compellingly
> close to the intended need, it doesn't explicitly state that "name"
> MAY or MUST NOT include relative directory paths. My naive
> reading/understanding is that the "name" is just the name of the file
> itself, the so called "basename" of a complete filepath value. At
> least, having "name" be defined to have this concrete purpose seems
> to have cross-cutting value.
> 
> My purpose seems twisted by comparison, to the extent that I question
> if any other tool would want or need to know an inclusion's original
> filepath value. On the other hand, "originalSrc" is semantically
> perfect for my needs. Let me turn this around and ask, why does
> preptool use "originalSrc" as opposed to "name" and, that being the
> case, how is it any different for xiax?

I don't have information beyond what's given in RFC 7991 and RFC 7998,
but in my mind the distinction is this:  The "src" and "originalSrc"
attributes are for the use of the preptool when moving external sources
into the xml file for the purpose of having one single archival entity
(file).  There is no semantic defined for reversing this.

Unfortunately, item 1 and 4 in Section 5.5.1 of RFC 7998[1] seems to set
up a situation where the "src" value will be moved to "originalSrc" in
some cases and not in others, and where pre-existence of "orgiginalSrc"
will change the behaviour.  This makes it unintended effects possible if
other tools also use the "originalSrc" value.  (Mmm.  I think we need to
revisit this part of RFC 7998 to make the conditions under which "src",
"originalSrc", or both will exist).

On top of this, Section 5.6.5 of RFC 7998 [2] specifies that "originalSrc"
be removed as part of publication; and Section 5.5.1 specifies that "src"
will be removed (in some?? cases) when "originalSrc" is filled in, which
leaves you with neither "src" or "originalSrc" in the published document...

I'd be happiest if other tools did not touch "originalSrc", and only
used "src" in order to point at external documents for inclusion by
xml2rfc.  That would avoid tool interdependencies.

We then need to either make "name" useful for your purpose, or provide
another way (possibly an xiax:name attribute) that will do.


Best regards,

	Henrik


[1]  https://tools.ietf.org/html/rfc7998#section-5.5.1
[2]  https://tools.ietf.org/html/rfc7998#section-5.6.5