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

Robert Wilton <> Mon, 04 March 2019 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C96F12D829 for <>; Mon, 4 Mar 2019 08:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 6RoFRRF70Qea for <>; Mon, 4 Mar 2019 08:24:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EEA4128B14 for <>; Mon, 4 Mar 2019 08:24:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2311; q=dns/txt; s=iport; t=1551716691; x=1552926291; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7QJ+L8XvOsOPlDrhxUeLGDH6RjKWU+DiZrBebNFHwbs=; b=jc6JglAplqdp0+W6lIBfVSIBs8XcMTHlgINmXOiK/beVbdzWmMZPTNOc 9k3BfLk2n650W8isgkY/5/auofzpdfvusMPYEWL28GsgKS6ozIXpgpXxy YhyNQkxK1SHybabd56x3dXSuMRRd29j6jEsDkYZWoNsmvXQOhdKskcX2c 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.58,440,1544486400"; d="scan'208";a="10538318"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 16:24:48 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id x24GOmco024122; Mon, 4 Mar 2019 16:24:48 GMT
To: Martin Bjorklund <>,
References: <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Mon, 04 Mar 2019 16:24:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 16:24:54 -0000

The nice thing with the two slash approach is that it always works.  It 
doesn't matter whether it is text or XML, you just strip what is between 
the two slashes.

The C '\' approach doesn't really work with indentation, and I'm not 
convinced that extracting code from text RFCs is dead just yet.

Martin's strip leading white space approach doesn't safely work with 
documents that may contain meaningful white space.  Will everyone also 
include the trailing space at the end of the line before the '\' when 

I still think that the double slash approach is sufficient on its own.

If we must have two, then I would suggest the double slash approach, and 
also Martin's, but perhaps use '+' instead or '\'.


On 04/03/2019 16:04, Martin Bjorklund wrote:
> Kent Watsen <> wrote:
>>> 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.
> I am confused.  Are you saying that the unfolding algorithm only is
> supposed to work on data extracted from the XML version of the I-D or
> RFC?  If so, I think this needs to be clarified in the draft.
>> 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.
> ... as does the single-backslash with leading space removal.
> /martin
>> 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.
>> [1]
>> Kent
> .