Re: [Rswg] draft-mcquistin-augmented-ascii-diagrams

Colin Perkins <csp@csperkins.org> Sat, 28 October 2023 14:50 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rswg@ietfa.amsl.com
Delivered-To: rswg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D107C15C2AB for <rswg@ietfa.amsl.com>; Sat, 28 Oct 2023 07:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.406
X-Spam-Level:
X-Spam-Status: No, score=-4.406 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
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 RktAbQMXszfc for <rswg@ietfa.amsl.com>; Sat, 28 Oct 2023 07:50:42 -0700 (PDT)
Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D67C1519B3 for <rswg@rfc-editor.org>; Sat, 28 Oct 2023 07:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=WWZZRawjDajBNoe6NBupIShdPL2+Z/VGTXL9WpPwSZM=; b=Q3xnakMWo/bSg8HE4oqKFYxLOZ O8Qto+7nbdICA6sqT5/FZwctm4F5hVkT9r/ZOd0cmv67crPkB0mISh/O/tYLiXJ9hMM8U+KSWPKck 6g5JaLI/du2LC9DVuJGlZS+a9NF//xZ5X2v5BJqp4Bohl+ott4bmUFVhfuwYDe8QGaGvvHi0mUhLZ Ro52nC+tnbJXcPLUe2Wh39j795YEj7RA01YdKCn7t2OqqrhiYYPKOTHWXo0NlLXCMPVF//23GotdX LJoIA/YMyysQlQ5wn+beC2N6aUypZq6W3XrIcQ3375CPtBDcQQRE13JyIkeNbEBcaoFwRY0o34fY/ hpyTCx9A==;
Received: by mailhub-hex-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <csp@csperkins.org>) id 1qwke9-009VD3-1Z for rswg@rfc-editor.org; Sat, 28 Oct 2023 15:50:41 +0100
From: Colin Perkins <csp@csperkins.org>
To: rswg@rfc-editor.org
Date: Sat, 28 Oct 2023 15:50:38 +0100
X-Mailer: MailMate (1.14r5998)
Message-ID: <2F1EAE87-FB96-44E1-A0D1-38EC69A1EA02@csperkins.org>
In-Reply-To: <23c31faa-0a02-4d50-bce1-f5675fdcbe8c@gmx.de>
References: <20231027211651.842B65B85677@ary.fritz.box> <23c31faa-0a02-4d50-bce1-f5675fdcbe8c@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_991C7876-C690-4B30-8804-B7A89BDD0CAE_="
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/IT5qLUTvXofc-FyS002RAGSfFbc>
Subject: Re: [Rswg] draft-mcquistin-augmented-ascii-diagrams
X-BeenThere: rswg@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RFC Series Working Group \(RSWG\)" <rswg.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rswg>, <mailto:rswg-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rswg/>
List-Post: <mailto:rswg@rfc-editor.org>
List-Help: <mailto:rswg-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rswg>, <mailto:rswg-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Oct 2023 14:50:47 -0000

On 28 Oct 2023, at 11:03, Julian Reschke wrote:
> On 27.10.2023 23:16, John Levine wrote:
>> ...
>>> - potential to use with Martin's AASVG
>>> - doubt that we should parse english prose when we actually have a
>>> markup language to express RFCs
>>
>> I agree that the idea is fine, but the hacks to embed it in text RFCs
>> are not.  I think we could make it an <artwork> type, say that they
>> have to match the grammar, sort of like SVG does, and say it is
>> specificallt allowed for rendering engines for HTML et al to
>> parse them and redraw them using actual lines and boxes.
>
> Right.

The entire point of this draft is that it doesn't require any change to 
the RFC format. It doesn't need to be embedded into artwork, source 
code, media types, or anything of the sort. It's a structured way of 
using the existing RFC format, unchanged, and usable **today** (and, 
indeed, with any variant of the RFC format we've had in the last few 
decades).

We could define something more structured, more integrated with the RFC 
format. That would be a useful thing to do. It could probably build on 
the same underlying data description model and code base. But it's not 
the purpose of **this** draft.

Colin