IETF Logo Mail Archive

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

Marc Petit-Huguenin <marc@petit-huguenin.org> Sat, 25 November 2023 15:25 UTC

Return-Path: <marc@petit-huguenin.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 51FAAC151099 for <rfc-interest@ietfa.amsl.com>; Sat, 25 Nov 2023 07:25:48 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-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 Te4fLo64rgtj for <rfc-interest@ietfa.amsl.com>; Sat, 25 Nov 2023 07:25:43 -0800 (PST)
Received: from implementers.org (implementers.org [92.243.22.217]) (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 6E4A1C15107F for <rfc-interest@rfc-editor.org>; Sat, 25 Nov 2023 07:25:41 -0800 (PST)
Received: from [IPV6:2601:204:e37e:6938:d250:99ff:fedf:93cf] (unknown [IPv6:2601:204:e37e:6938:d250:99ff:fedf:93cf]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C4449AE534; Sat, 25 Nov 2023 16:25:38 +0100 (CET)
Message-ID: <ad787186-41d5-4a04-b49a-62fffc897bc6@petit-huguenin.org>
Date: Sat, 25 Nov 2023 07:25:35 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: "Paul Duffy (paduffy)" <paduffy@cisco.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>
References: <310371.1700735021@dyas> <7C81D316-7D04-4941-BEE5-6AE8C96F0DE1@tzi.org> <D1F8F86E-80D7-4FC7-B7B5-32648ACB5D65@tzi.org> <MN2PR11MB3757AF8CCDF388BA5CECFE1AB9B8A@MN2PR11MB3757.namprd11.prod.outlook.com> <153bde12-5773-42ce-bfdf-392e4492c06b@gmx.de> <MN2PR11MB375791C859512AB08EA20D11B9B8A@MN2PR11MB3757.namprd11.prod.outlook.com> <61DE9E4A-5242-42A9-B88D-30BEBF16AB0E@tzi.org> <MN2PR11MB3757F829830FBD6E1EB3C72FB9B8A@MN2PR11MB3757.namprd11.prod.outlook.com> <9fd054a6-ed51-4ca6-8fbe-f7ff78bf3c8b@alum.mit.edu> <BN8PR11MB374614B320B56093ECA275F2B9BFA@BN8PR11MB3746.namprd11.prod.outlook.com>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
Content-Language: en-US
Autocrypt: addr=marc@petit-huguenin.org; keydata= xsFNBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABzS1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz7CwXsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyzsFNBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABwsFfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ
In-Reply-To: <BN8PR11MB374614B320B56093ECA275F2B9BFA@BN8PR11MB3746.namprd11.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------icu4kP3wNhF10cdg9S0xmpPo"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/XqWAjxmXiSBLAsvVs7Rys1p5e2M>
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: Sat, 25 Nov 2023 15:25:48 -0000

On 11/25/23 07:11, Paul Duffy (paduffy) wrote:
> IMO what is needed is IETF ability to support multi part documents with the durability of single part RFCs.  Main body being the RFC itself with code section references ... all durably stored and accessible.

How is that not already provided by the XML file hosted by the RFC Editor (the only canonical form of an RFC, all other formats being lossy views of that file)?

> 
> -----Original Message-----
> From: rfc-interest <rfc-interest-bounces@rfc-editor.org> On Behalf Of Paul Kyzivat
> Sent: Friday, November 24, 2023 6:51 PM
> To: rfc-interest@rfc-editor.org
> Subject: Re: [rfc-i] getting SVG of RFC diagrams
> 
> On 11/24/23 9:57 AM, Paul Duffy (paduffy) wrote:
>> Inlining of any code snippets beyond a few lines long IMO is nothing more that aggravation and friction for the developer community that needs the ability to quickly inject the source into useful tooling.
>>
>> And inlining often leads to a nearly unreadable mess in the RFC.
> The inlining is needed in order to preserve the stability of RFC over time, regardless of what might happen to the original sources. You could of course put an explicit reference to the original source in your document.
> 
> An alternative that I think I have seen discussed, is to leave the reference but also have an IETF managed backup, that automatically takes over if the original link is broken. But there is much complexity here.
> 
> 	Thanks,
> 	Paul
> 
>> -----Original Message-----
>> From: Carsten Bormann <cabo@tzi.org>
>> Sent: Friday, November 24, 2023 9:44 AM
>> To: Paul Duffy (paduffy) <paduffy@cisco.com>
>> Cc: rfc-interest@rfc-editor.org
>> Subject: Re: [rfc-i] getting SVG of RFC diagrams
>>
>> On 2023-11-24, at 15:39, Paul Duffy (paduffy) <paduffy=40cisco.com@dmarc.ietf.org> wrote:
>>>
>>> Help me understand.
>>>
>>> https://datatracker.ietf.org/doc/draft-duffy-csmp/
>>>
>>> Section 3.2.1
>>>
>>> Originally provided as link to external OpenAPI. Super easy for developer to import that link directly into OpenAPI tooling.
>>
>> Makes sense during development.
>>
>>> I was told this will not acceptable and must be inlined into the draft.
>>
>> Once you enter WGLC and IESG processing, yes.
>>
>> This leads to the desirability of the URI convention described by me.
>>
>> Grüße, Carsten
>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

v2.23.0 | Report a Bug | By Email