Re: [rfc-i] [Ietf-and-github] 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: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA2130DC9 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 26 Feb 2019 12:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.2
X-Spam-Level:
X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 zt3FcAF2TEE3 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 26 Feb 2019 12:12:33 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AA8130E27 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Tue, 26 Feb 2019 12:12:33 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id C0653B800EC; Tue, 26 Feb 2019 12:12:12 -0800 (PST)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 1E196B800E9 for <rfc-interest@rfc-editor.org>; Tue, 26 Feb 2019 12:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpH79syEsYvo for <rfc-interest@rfc-editor.org>; Tue, 26 Feb 2019 12:12:09 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) by rfc-editor.org (Postfix) with ESMTPS id 70C3CB800E1 for <rfc-interest@rfc-editor.org>; Tue, 26 Feb 2019 12:12:09 -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>
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>
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
Subject: Re: [rfc-i] [Ietf-and-github] New Version Notification for draft-kwatsen-git-xiax-automation-00.txt
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: RFC Interest <rfc-interest@rfc-editor.org>, ietf-and-github@ietf.org
Content-Type: multipart/mixed; boundary="===============5345525879553863205=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

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


_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest