[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
- [rfc-i] t with indent Eric Rescorla
- Re: [rfc-i] t with indent Julian Reschke
- Re: [rfc-i] t with indent Eric Rescorla
- Re: [rfc-i] t with indent Eric Rescorla
- Re: [rfc-i] t with indent John R Levine
- Re: [rfc-i] t with indent Julian Reschke
- Re: [rfc-i] t with indent Eric Rescorla
- Re: [rfc-i] t with indent John R Levine
- Re: [rfc-i] t with indent Carsten Bormann
- Re: [rfc-i] t with indent Mark Nottingham
- Re: [rfc-i] t with indent Julian Reschke
- Re: [rfc-i] t with indent Julian Reschke