[rfc-i] t with indent

Eric Rescorla <ekr@rtfm.com> Tue, 29 December 2020 19:09 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33653A083B; Tue, 29 Dec 2020 11:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY-ZVx0d3dyt; Tue, 29 Dec 2020 11:09:30 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6063A0827; Tue, 29 Dec 2020 11:09:30 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id B370CF406CD; Tue, 29 Dec 2020 11:08:59 -0800 (PST)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 709DBF406CD for <rfc-interest@rfc-editor.org>; Tue, 29 Dec 2020 11:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYmi-O_-3vyB for <rfc-interest@rfc-editor.org>; Tue, 29 Dec 2020 11:08:55 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by rfc-editor.org (Postfix) with ESMTPS id 90252F406C6 for <rfc-interest@rfc-editor.org>; Tue, 29 Dec 2020 11:08:55 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id 23so32852265lfg.10 for <rfc-interest@rfc-editor.org>; Tue, 29 Dec 2020 11:09:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=qGl2Vf+LSDMqO8BI/qH8COku2RAZ9wtC0wVfSES/kCo=; b=J8mJEEfQsrBaiaGM9YaRWerEwfenFH0dRL4VQqw8hgsOyODIO81gmV0FoaVLIAyXKy 1T+KOcZ340ubMTM0xw9lWwIiJd7EkpGJ9CvaEaZdw1AzNVhwQqGU7cfFnhvm9brrvSPd 7HNkM8oxcz9dZweBdVZnQ6m3nT+nfIL/2qYRtWvxRnD5Tmd10HiD6EA4QY0uM+73kcn9 ttdm9CelN8/iWUwJBz9RGUB8v3PFBpDJ9TtCxscXR7ggShdTbJSuFcPhNapo2eXsu3TQ Y3MYM40CEHthklastGPZtWIgOedHw07vXBLDIvoXoXiBF3u6OErs37lthjLr6eCWQPvF vaHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qGl2Vf+LSDMqO8BI/qH8COku2RAZ9wtC0wVfSES/kCo=; b=RywFRLUDV1SBv+ZTQZNW+oo+nFlhKCtG5xNfEseXH+IKTw9OLNU8KVYpB4He8uMQBO wFVQnYbh6wlYGJY2HRMPEphztc7YyQYNj0X8/Qz5lsHrj7a1i2iwbMKbLnITT+xN5e8Z AaP3PrICi+uv+GtIYXxzg3rbBdKDnWAufxH4Vah5rJ1CGaJMd99uiXToKjTMgLZAthSR /d91cV1FpupgwzS6EhAkwF5kAO8FjODo1j8fMImqGKFmJOsO3xRUa69oQfNXMH71L38z FbSkMgAMS5BQrszeXGWivpcuNIRL+xg7Bh89ef+VyJ9bzZr7cJdW6gzMG1MkdM9exyDv /7tA==
X-Gm-Message-State: AOAM5319iESYZIVtRnoPDSqtrEpxjkPZH5IbDMmVlV07rjqyiXCOfWvx 2GcwkL/Cb8iDwCyR45DmrPLhpfe9B7tSTZRQDMlJk9YPzzUZKoZL
X-Google-Smtp-Source: ABdhPJzwOJstvDMXkMQbV3ERUAEiP38ygpJtGQr/KFOOufqhLu9pHYm4JwvHvrXuMsF0ffnYNvOASz8LoxwggblDTkg=
X-Received: by 2002:a2e:9f53:: with SMTP id v19mr23775924ljk.109.1609268960517; Tue, 29 Dec 2020 11:09:20 -0800 (PST)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 29 Dec 2020 11:08:42 -0800
Message-ID: <CABcZeBOvxuD0pnWrkcywcKBMsd4CuCrLB4YkmDStpwh7e-SkSA@mail.gmail.com>
To: RFC Interest <rfc-interest@rfc-editor.org>
Subject: [rfc-i] t with indent
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2726807229000486178=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>

Hi folks,

In doing Auth48 for RFC8844 I noticed that each <t> block in the final
XML seems too contain an "indent" attribute, as in:

   <t indent="0" pn="section-2-5">

While I see that the current v3 grammar seems to allow "indent" under
<t>, this doesn't seem to be in draft-iab-rfc7991bis, so it's not
quite clear what purpose it's intended for. This seems to raise two
questions:


First, do we really want this kind of layout-specific markup rather
than semantic markup? Searching for <t> with indent != 0 in the
published RFCs, I see the following cases:

- RFC 8907, S. 6.2 -- a definition list nested in another definition list

- RFC 8916, S. 5 -- a definition list indented under a hed (arguably
                    another nested definition list)

- RFC 8919 S 7.3 -- a set of Note: values introduced by a sentence
                    ending in a colon

- RFC 8934 S 4.2.2 -- an equation

- RFC 8949 S 8 -- an equation

It seems like we might be better served here by introducing some new
semantic constructs. Both nested definition lists and equations are
natural structures that would benefit from consistent layout (note:
it's possible that nested definition lists already exist; it wasn't
quite clear to me from the grammar). RFC 8919 is kind of an edge:
one could probably model it as a definition list or one could just
live with the Notes not being indented.


Second, even assuming that <t indent=...> is a good thing, it seems
suboptimal to have it attached to every paragraph in the XML. Is
there a reason why it can't simply be omitted when it is set to
the modal value of "0"?

-Ekr
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest