Re: [netmod] artwork folding: dual support modes?

Kent Watsen <> Mon, 04 March 2019 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C5EF1310E9 for <>; Mon, 4 Mar 2019 07:48:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q96qQhfpO7mR for <>; Mon, 4 Mar 2019 07:48:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1D791310D5 for <>; Mon, 4 Mar 2019 07:48:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1551714517; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DR0Jqn016nfyN5O8M/VIStQJMpW6VDM3bxl87E5XDs8=; b=UVG9wkFjL8GM0ddHVBhX1HDLnAYkXMPE6i7Q6vFI7Nf/yEmk7yW2mPcUQ+91rzoD J9lRAWUQAMe3qgcO5B4D8p+LGljSajCDFNfVhlduy787+lvwBZcqz70kD5zHC8+Sf14 6gfeB763TYO36pB+M/7LTgsb3CY+GyV96yrdDFMs=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_96A21EA2-FFD8-40B6-97D5-2DB3B5A31D23"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 04 Mar 2019 15:48:36 +0000
In-Reply-To: <>
To: Martin Bjorklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.03.04-
Archived-At: <>
Subject: Re: [netmod] artwork folding: dual support modes?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Mar 2019 15:48:41 -0000

> But note that figures in RFCs are normally indented with 3 spaces
> (they _can_ be outdented, if the lines are long enough).

The days of scraping from plain-text RFCs are over [1].  Extracting, if needed at all, should be from the XML, where there are no such issues. Extracting from the plain-text output makes about as much sense as extracting from the HTML or PDF outputs.

Lossless extractions are critical for formal verifications (e.g., doctor reviews, shepherd reviews, AUTH48 reviews).   Both the double-backslash approach we currently have, and the single-backslash approach we had originally (where the continuation-line begins on column 1, as it has been in programming languages for decades) provide lossless extractions.

The double-backslash approach is ideal for when pretty-indents are desired.   The single-backslash approach is ideal for when the pretty-indents are not needed.  Both are completely valid and useful.   My contention is that we unnecessarily threw out one when reaching for the other.