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
- [Ietf-and-github] Fwd: New Version Notification f… Kent Watsen
- Re: [Ietf-and-github] New Version Notification fo… Kent Watsen
- Re: [Ietf-and-github] [rfc-i] Fwd: New Version No… Julian Reschke
- Re: [Ietf-and-github] New Version Notification fo… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Kent Watsen
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Julian Reschke
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Kent Watsen
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Joel M. Halpern
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Julian Reschke
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Stephan Wenger
- Re: [Ietf-and-github] New Version Notification fo… Kent Watsen
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Julian Reschke
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Julian Reschke
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Kent Watsen
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Henrik Levkowetz
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Kent Watsen
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Carsten Bormann
- Re: [Ietf-and-github] [rfc-i] New Version Notific… Kent Watsen