Re: [Rswg] A citation as a substantive [was draft-irse-xml2rfc-changes...]
John C Klensin <john-ietf@jck.com> Wed, 28 September 2022 17:40 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: rswg@ietfa.amsl.com
Delivered-To: rswg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88683C14CF10 for <rswg@ietfa.amsl.com>; Wed, 28 Sep 2022 10:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLZgwN7UMGAJ for <rswg@ietfa.amsl.com>; Wed, 28 Sep 2022 10:40:36 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C211C14EB1C for <rswg@rfc-editor.org>; Wed, 28 Sep 2022 10:40:35 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1odb2w-000KhA-Bb; Wed, 28 Sep 2022 13:40:34 -0400
Date: Wed, 28 Sep 2022 13:40:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: Julian Reschke <julian.reschke@gmx.de>, rswg@rfc-editor.org
Message-ID: <B0350AE53001A41BEF7C0114@PSB>
In-Reply-To: <021ea908-85e6-a3eb-a539-4afb603ace14@gmx.de>
References: <interim-rfc-series-project-manager/draft-irse-xml2rfc-changes/issues/1@github.com> <interim-rfc-series-project-manager/draft-irse-xml2rfc-changes/is sues/1/1259679973@github.com> <YzNE5EIA7HI0WsEk@faui48e.informatik.uni-erlangen.de> <0276E311EA9F8008B13ABEBE@PSB> <4ee10c7a-506c-3799-a726-6f9147e4b58c@gmail.com> <035f585b-d96e-ac89-7964-2ae0f2cb56cf@cs.tcd.ie> <91e44938-8549-4acc-9be8-85c74603552a@amsl.com> <1AFA9E0F699E174E121DF124@PSB> <021ea908-85e6-a3eb-a539-4afb603ace14@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/ilyd3NQJYhDcsauc4FNvQBE0kL4>
Subject: Re: [Rswg] A citation as a substantive [was draft-irse-xml2rfc-changes...]
X-BeenThere: rswg@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RFC Series Working Group \(RSWG\)" <rswg.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rswg>, <mailto:rswg-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rswg/>
List-Post: <mailto:rswg@rfc-editor.org>
List-Help: <mailto:rswg-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rswg>, <mailto:rswg-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2022 17:40:40 -0000
Response to Julian, in probably more detail than he wished for, inline but: (a) Question for the co-chairs: How deeply into this swamp do you consider it worthwhile to descend at this point? Should we pose the issues and wait for a recommendation for the RPC and/or RSCE as suggested/explained below or continue to have at it? (b) Note to John Levine: Discussed in more detail inline but, in looking at draft-irse-draft-irse-xml2rfcv3-implemented-03 (and its RFC Editor Function predecessor), it appears that a least some of the new/added attributes ("section" for <xref> in this case) lack definitions of what is permitted in their values. Clearly some definition has been implemented so, as your document continues to evolve, it would probably be worth tracking those attributes down and completing the definitions. Now for the more substantive issues... --On Wednesday, September 28, 2022 17:52 +0200 Julian Reschke <julian.reschke@gmx.de> wrote: > Am 28.09.2022 um 17:21 schrieb John C Klensin: >> >> >> --On Wednesday, September 28, 2022 08:35 -0500 Jean Mahoney >> <jmahoney@amsl.com> wrote: >> >>>> I don't object to guidance as to better phrasing at all, >>>> but imposing such as a requirement seems a bit silly when >>>> the meaning is clear. >>> >>> [JM] The current guidance for in-text citations can be >>> found in the RECOMMENDED section of the Web Portion of the >>> Style Guide. Both styles are okay: >>> https://www.rfc-editor.org/styleguide/part2/#citation_usage >> >> Jean, >> >> My apologies to you, and everyone else, for mentioning that >> issue in my note because it seems to have distracted from the >> more important question, one that I do not believe is >> addressed in the Style Guide. That is whether, if one needs >> to cite, e.g. (and simplifying a bit from Toerless's >> example), two different sections of the same document, >> whether you have guidance about whether to use some variation >> on >> >> The background for the current Nomcom selection criteria >> [RFC8989] Section 1,... >> >> and >> >> The specific, experimental Nomcom criteria [RFC8989] >> Section 4... >> >> or whether to embed the section number in the references so >> one would have simply "[RFC8989a]" and "[RFC8989b]" in the >> running text. That second form is probably more friendly to >> both Toerless's concerns about very complex within-document >> citations and to HTML formats, where an author could actually >> specify a link of >> <https://www.rfc-editor.org/info/rfc8989#Section1> if that >> anchor were supported in the text (it is not for RFCs, but >> could easily be available for other types of documents). >> >> >> As far as I can tell, the current RFCXML vocabulary is not >> particularly friendly to either. For the first form and itsy >> "[RFC8989 Section 1]" to "[RFC8989] Section 1" >> because the former would make it more clear that "Section 1" >> is part of the citation and not running text. However, I >> cannot write >> <xref target="RFC8959" citationDetail="Section 1"/> >> or the equivalent, which I presume would be needed to produce >> it. > > You could write > > <xref target="RFC8959" section="1"/> > > This will produce > > Section 1 of [RFC8959] > > with both parts nicely hyperlinked in formats that support > linking. > > > ... Noting that a "section" attribute does not appear in RFC 7991, I obviously have not been tracking the vocabulary closely enough, instead prioritizing actually getting documents written and, apparently, reading this list, for which I guess I should apologize. However: While the above works for "an RFC or Internet-Draft in the v3 format", it is an error for some other sort of document unless "relative" is also specified (Section 2.66.4 of [id.draft-iab-rfc7991bis-04] and Section 2.66.3 of [id.draft-iab-rfc7991bis-04]) The above illustrates several of the points I (and I think Toerless) were trying to ask Jean about. (1) For readability, the brackets should really be outside the entire citation, because "Section 1" is actually part of it. For the more complicated case I show above, the parentheses are needed to prevent things from becoming hopelessly confused. Maybe the two citations should be parenthesized separately, to be consistent with having references to two separate RFCs (e.g., "... [RFC7991][id.draft-iab-rfc7991bis-04]" or "[3][4]". (2) Even Section 3.66.5 of the "As Implemented" spec [id.draft-irse-draft-irse-xml2rfcv3-implemented-03] does not specify the potential values of the "section" attribute, so I can't figure out, without either experimenting or appeal to higher authority, whether I could write (for a different reference) <xref target="foo" section="Appendix D, part 2"/> your example with section="1"' hints that might not work. (3) Item (2) above also illustrates the citation bracketing problem. While it would be perfectly sensible to write either The "As implemented" spec [Section 3.66.5 of id.draft-irse-draft-irse-xml2rfcv3-implemented-03] or The "As implemented" spec [id.draft-irse-draft-irse-xml2rfcv3-implemented-03a] the sentence in (2) strikes me as awkward. YMMD and that may be partially a plain text problem. But having it as Even the "As Implemented" spec Section 3.66.5 [id.draft-irse-draft-irse-xml2rfcv3-implemented-03] which is presumably what would be generated using the section attribute, is, IMO, even more awkward and, I believe that, in the absence of a comma after "spec" also grammatically incorrect. So the comma belongs there in plain text but not in HTML where the whole business is a citation anchor and link? I am not optimistic about getting the right in the output generation process. (4) I also have no idea what the sentence in (2) would look like in an HTMLized process. We would either end up with the "Section 3.66.5" in plaintext (not a link) and a link into the references for the citation anchor or, with some clever heuristics and some lookahead, a link into the actual document (https://www.ietf.org/archive/id/draft-irse-draft-irse-xml2rfcv3-implemented-03.html#section-3.66.1) with the actual citation anchor still pointing to the references. Or maybe I'm still missing something but these seem to be more questions for Jean and her colleagues about their preferences and what the Style Manual should say. Once they have expressed opinions, the WG can decide whether to disagree or nit-pick. After there is agreement, I'm confident that we can reverse-engineer the RFCXML vocabulary to allow accommodating them (including any author flexibility they think appropriate). However, dropping a "section" attribute into the <xref> element without examining the issue that Toerless first raised (I'm just digging deeper) in this discussion, most of which have been raised on and off with the RFC Editor Function for decades, is exactly the sort of thing that causes some of us to feel that things are in rather a mess. best, john
- Re: [Rswg] [interim-rfc-series-project-manager/dr… Toerless Eckert
- Re: [Rswg] [interim-rfc-series-project-manager/dr… John C Klensin
- [Rswg] A citation as a substantive [was draft-irs… Brian E Carpenter
- Re: [Rswg] A citation as a substantive [was draft… Eric Rescorla
- Re: [Rswg] A citation as a substantive [was draft… John C Klensin
- Re: [Rswg] A citation as a substantive [was draft… Toerless Eckert
- Re: [Rswg] A citation as a substantive [was draft… Stephen Farrell
- Re: [Rswg] A citation as a substantive [was draft… Jean Mahoney
- Re: [Rswg] A citation as a substantive [was draft… John C Klensin
- Re: [Rswg] A citation as a substantive [was draft… Julian Reschke
- Re: [Rswg] A citation as a substantive [was draft… Jean Mahoney
- Re: [Rswg] A citation as a substantive [was draft… John C Klensin
- Re: [Rswg] A citation as a substantive [was draft… John C Klensin
- Re: [Rswg] A citation as a substantive [was draft… Julian Reschke