[xml2rfc] Discuss: <referencegroup rendering

Carsten Bormann <cabo@tzi.org> Fri, 20 January 2023 11:40 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFF9C15171D for <xml2rfc@ietfa.amsl.com>; Fri, 20 Jan 2023 03:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 6l0M4WjekG4h for <xml2rfc@ietfa.amsl.com>; Fri, 20 Jan 2023 03:40:30 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83412C14E514 for <xml2rfc@ietf.org>; Fri, 20 Jan 2023 03:40:29 -0800 (PST)
Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4NyyGy5PxzzDCcY; Fri, 20 Jan 2023 12:40:26 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 695907626.2591079-47259f56034e4eea19fb4d6de1c147de
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 20 Jan 2023 12:40:26 +0100
Message-Id: <51754223-E183-4EED-AF00-0742BBF944DB@tzi.org>
To: xml2rfc@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/Dj9zM4ZGuonS236NQ0sR7Rr0ai0>
Subject: [xml2rfc] Discuss: <referencegroup rendering
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: XML2RFC discussion list <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2023 11:40:34 -0000

When using a multi-document reference (e.g., BCP195 or STD96), bib.ietf.org provides a <referencegroup that includes <reference entries for each of the documents.  This works great.

Discussion points:

Sometimes, individual documents out of the multi-document reference need to be referenced. bib.ietf.org provides anchors for this, so this works right.  Unfortunately, the anchors are not readily visible, as in:

   [BCP195]   Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
              1.1", BCP 195, RFC 8996, March 2021.

              Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, November 2022.

              <https://www.rfc-editor.org/info/bcp195>

So a reference to 

   See [BCP195], in particular Section 10.1 of [RFC8996] and Section 1 of
   [RFC9325].

leads to some visual hunting where [RFC8996] and [RFC9325] could be (they are not explicit in the references section).

I note that RFC 7322 uses this style:

      See RFC 1034 [STD13].

…so the replacement text inserted by xml2rfc maybe should be “RFC 8996 [BCP195]”?

The section references into the individual documents themselves work great, by the way.
It is just hard to say/see that these are part of the BCP/STD.

Nit:

I also note that if I delete the @target for the <referencegroup, xml2rfc does not reinstate this (well, maybe that would be too hard, which is why I’m not deleting them routinely).  So maybe just ignore this observation.

Background:
https://github.com/httpwg/http-extensions/issues/2369

Grüße, Carsten