Re: [rfc-i] getting SVG of RFC diagrams

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 23 November 2023 15:43 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 BAB0AC14CF1E for <rfc-interest@ietfa.amsl.com>; Thu, 23 Nov 2023 07:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 g8-t4Wm9JXS3 for <rfc-interest@ietfa.amsl.com>; Thu, 23 Nov 2023 07:43:16 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624B7C14EB19 for <rfc-interest@rfc-editor.org>; Thu, 23 Nov 2023 07:43:16 -0800 (PST)
Received: from [10.32.60.128] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 3ANFhEQQ056823 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Nov 2023 08:43:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.128]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Carsten Bormann <cabo@tzi.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, rfc-interest@rfc-editor.org
Date: Thu, 23 Nov 2023 07:43:14 -0800
X-Mailer: MailMate (1.14r5937)
Message-ID: <28DAF5C6-61E7-4EFE-85CB-28A914582495@vpnc.org>
In-Reply-To: <B67B9F9D-6B0F-4B35-A92E-95982BC1EB10@tzi.org>
References: <310371.1700735021@dyas> <6062AA58-6798-4B82-9FE3-6FA1AF05F7CD@vpnc.org> <B67B9F9D-6B0F-4B35-A92E-95982BC1EB10@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/5v2_QJFhAGb_NlynyDH2cYkze2U>
Subject: Re: [rfc-i] getting SVG of RFC diagrams
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: Thu, 23 Nov 2023 15:43:20 -0000

On 23 Nov 2023, at 7:27, Carsten Bormann wrote:

> A fragment identifier doesn’t really help with extracting (while it would help with naming extracted SVG elements, but that is easy by using the id on the div above).
>
> (I think the underlying problem here is that browsers don’t provide for image extraction for SVG — does anybody know why?)

Ah. I figured that if there was a fragment identifier, and you opened that fragment in a new window/tab, you would get the SVG. I can now see that would not be interesting to the browser, though.

> I don’t think the RSWG designs the HTML.

RFC 7992 is one of the policies that governs the RFC Series. If you want to re-litigate RFC 9280, maybe start a new thread.

> I don’t understand why we would want the HTML file to autonomously provide extraction of attachments; I’m more interested in having a separate URI for each attachment similar to the way Paul Kyzivat showed.

That would probably be the most reliable way to do things. That would require an update to RFC 7990 (the framework) or 7992 (extraction can be done during the HTML output step).

--Paul Hoffman