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