[rpat] Links in draft-ietf-ohai-ohttp

Sandy Ginoza <sginoza@amsl.com> Fri, 06 October 2023 19:54 UTC

Return-Path: <sginoza@amsl.com>
X-Original-To: rpat@ietfa.amsl.com
Delivered-To: rpat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF6BC14CE42 for <rpat@ietfa.amsl.com>; Fri, 6 Oct 2023 12:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 5GLlqLoy5b3F for <rpat@ietfa.amsl.com>; Fri, 6 Oct 2023 12:54:34 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (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 2147CC1519AE for <rpat@rfc-editor.org>; Fri, 6 Oct 2023 12:54:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E7728424B42D for <rpat@rfc-editor.org>; Fri, 6 Oct 2023 12:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz0HZXctfT36 for <rpat@rfc-editor.org>; Fri, 6 Oct 2023 12:54:21 -0700 (PDT)
Received: from smtpclient.apple (2603-8000-9603-b513-bc7b-4410-a836-0751.res6.spectrum.com [IPv6:2603:8000:9603:b513:bc7b:4410:a836:751]) by c8a.amsl.com (Postfix) with ESMTPSA id CB398424B42C for <rpat@rfc-editor.org>; Fri, 6 Oct 2023 12:54:21 -0700 (PDT)
From: Sandy Ginoza <sginoza@amsl.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D5BB7792-FE75-4B41-8627-8B6EF2497E86"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Message-Id: <3E475506-CF08-4177-B6AC-A3272597B3E5@amsl.com>
Date: Fri, 06 Oct 2023 12:52:45 -0700
To: rpat <rpat@rfc-editor.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rpat/YGFtoANxSBEE_QMIgU_VR6FyDJU>
Subject: [rpat] Links in draft-ietf-ohai-ohttp
X-BeenThere: rpat@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RFC Production Advisory Team - Provides operational advice to the RFC Production Center <rpat.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rpat>, <mailto:rpat-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rpat/>
List-Post: <mailto:rpat@rfc-editor.org>
List-Help: <mailto:rpat-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rpat>, <mailto:rpat-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2023 19:54:36 -0000

Greetings all,

draft-ietf-ohai-ohttp <https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-10.html> contains a number of links that are invisible to the user because they are not differentiated from the surrounding text (i.e., they appear in black, see #5071 <https://github.com/ietf-tools/datatracker/pull/5071> regarding "lighter styling on internal irefs”).  Note that the display is tied to a combined use of <xref> and <iref>, so links that typically appear in blue are now displayed in black (for example, in Section 2 <https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-10.html#section-2>, compare how the link to "Section 8.2" appears as opposed to the the links for "Oblivious Gateway Resource”).

Our understanding is that links should be easily differentiable from surrounding text so the reader is aware of their presence.  Do you think it's acceptable for this styling to appear in RFCs?

Note that the links in earlier versions of draft-ietf-ohai-ohttp <https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-08.html> were distracting.  There was some discussion about this within the IESG, but excessive linking was not considered a blocking issue (see https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/ballot/>).  

If the lighter styling is not acceptable, it seems the authors should be encouraged to use <xref> to definitions and <irefs> more judiciously. 

Thanks,
Sandy