Re: [rfc-i] archiving outlinks in RFCs

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 26 April 2023 03:12 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA632C159495 for <rfc-interest@ietfa.amsl.com>; Tue, 25 Apr 2023 20:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZCzYwSODjd7i for <rfc-interest@ietfa.amsl.com>; Tue, 25 Apr 2023 20:12:37 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 296BAC153CA0 for <rfc-interest@rfc-editor.org>; Tue, 25 Apr 2023 20:12:37 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1a52667955dso69726695ad.1 for <rfc-interest@rfc-editor.org>; Tue, 25 Apr 2023 20:12:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682478756; x=1685070756; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=j5PJi6MTRTemGZNmEFoNC+ozrajKhacO7o95a/IK6bI=; b=fuQFmsEl10oZbDtmkh80DTo0yHVs+NB0ymCjZ8eL9WT45rAGJBhw8Kjf1vuddZzaBI 4oV9CvNELFN+jmhG8yzbuxP1UsfPN+/YUxklm0mpOEa+m4wqGYTrEXphQZbIn4D/wp1e T1Rpt5LJnFMM8s8jNhq9inkX3hKjgGO0T/QwBKuhvLIwry2p+UiBbHcZ42+d8Umhj21r 19iwIMk2vszH6iadGYetfnZ1l5StlWkWVq47nFTZLNr+sgvjn0+e5VBtZ3xxv9hs6yt3 PlBLq/w2donKdJYA7XFDqdKD848Q8L/lUeQ78VgzRh5DaP4g9loo712/LmBT9gJpD3JZ WWlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682478756; x=1685070756; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=j5PJi6MTRTemGZNmEFoNC+ozrajKhacO7o95a/IK6bI=; b=TbvQTfRyPI+XotLct5PakmsMTgHqCELV4eVfp5JIBaTYAGB29cA6WtBKuDPXZceUC5 IQB1O8slCqxtYxvou6DMz8pbo721ygZm8L89ArWFnfUkQ2UQzL9KuJbuLvDGlVaSV8Xt 4EvvEo/dJabntovUBtdpEK7ClrB6vHZ8MeuzXtdZ6UFcOAo1uXZivoAuSpU7cV4muwcd 9hSaT35wJOK6wMFE4YQyy3ZFXX3jF+qCgG4klMYcssTnAmTDDlGQt2jx+DNzlZVQv83Q /ulXZJgVvGhdN/pVVij0iL6SvBw6H0VZY1bpIjBmbmbFudwHgIuFU10Dkrp5mtBafwMp SHIA==
X-Gm-Message-State: AAQBX9dxOCKgQjnblpWqkPN355V3PoAiRPgOMt7NEcp39NzsXEO91k4L H9NmfFSJxEpy8S/zjZCSHyA=
X-Google-Smtp-Source: AKy350aH3s+9bNxjmstQBIlD16/pQdTBPzcheG7ABoAEhe8oOVZxPaiLAVUQCFebPR91GqkLWDMIGw==
X-Received: by 2002:a17:902:f651:b0:19e:f315:98d with SMTP id m17-20020a170902f65100b0019ef315098dmr22289648plg.43.1682478755998; Tue, 25 Apr 2023 20:12:35 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:9991:d1ad:8c20:42bd? ([2406:e003:1184:f001:9991:d1ad:8c20:42bd]) by smtp.gmail.com with ESMTPSA id c6-20020a170902b68600b001a4edbab9c4sm5736582pls.254.2023.04.25.20.12.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Apr 2023 20:12:35 -0700 (PDT)
Message-ID: <3359f587-fd5f-a610-7252-7b96ab1b35ca@gmail.com>
Date: Wed, 26 Apr 2023 15:12:31 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Martin Thomson <mt@lowentropy.net>, Eric Rescorla <ekr@rtfm.com>
Cc: rfc-interest@rfc-editor.org
References: <E024D9AC-2B92-4720-9713-519592D2362B@rfc-editor.org> <30c30c2f-4e96-560a-73dd-a51ba8d04714@comcast.net> <771B7586-FFBB-49E4-9B99-5578863FBD8B@rfc-editor.org> <CABcZeBOevOj8cWY7dacWxzwZS82+iAjf1p+DZWF=7WZ9JydnrQ@mail.gmail.com> <48de4d92-e279-4c26-ab3c-15dd854b56f8@betaapp.fastmail.com> <CABcZeBPqePQwPAq5pWda1pGaY_=kLkcOxCjZWmOv9yRZ_MNb7g@mail.gmail.com> <7674faf7-6bc8-41d6-80dd-f68e63c8d371@betaapp.fastmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <7674faf7-6bc8-41d6-80dd-f68e63c8d371@betaapp.fastmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/_U8KeZpgoEj6cHd7JcOEsADk31g>
Subject: Re: [rfc-i] archiving outlinks in RFCs
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2023 03:12:40 -0000

On 26-Apr-23 12:17, Martin Thomson wrote:
> On Wed, Apr 26, 2023, at 09:55, Eric Rescorla wrote:
>> Obviously the line between "style" and "content" is a fine, but istm that the
>> line you propose to draw would allow the RPC to take all the MUSTs, style
>> them out with CSS, and replace them with MUST NOTs.
> 
> Well, different renderings choose different destinations for links to RFCs, I think.  So we seem to be on the edge there.  And we have inline errata renderings.  I guess your position is that those are in scope for approval here too.

I don't see why. Errata approval is a stream function, but that's about content, not rendering.

Broken links are indeed on the edge, but "do the right thing" applies, doesn't it? If the sense of the room is that pointing to archived pages is the right thing, I'm not sure we'd really need an RFC saying so.

    Brian

> 
> I should try swapping MUST and MUST NOT in CSS, that would be ... interesting.
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest