Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)

Martin Bjorklund <mbj@tail-f.com> Fri, 06 September 2019 07:25 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29F612007C for <netmod@ietfa.amsl.com>; Fri, 6 Sep 2019 00:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 M8eYywZbc017 for <netmod@ietfa.amsl.com>; Fri, 6 Sep 2019 00:25:17 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3D5B12002E for <netmod@ietf.org>; Fri, 6 Sep 2019 00:25:16 -0700 (PDT)
Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 868C01AE0187; Fri, 6 Sep 2019 09:25:15 +0200 (CEST)
Date: Fri, 06 Sep 2019 09:25:15 +0200 (CEST)
Message-Id: <20190906.092515.2154852591644890692.mbj@tail-f.com>
To: auerswal@unix-ag.uni-kl.de
Cc: kent+ietf@watsen.net, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20190905163216.GA3497@unix-ag.uni-kl.de>
References: <0100016d01f89905-2d99967e-a660-4ae2-a0a3-1fd270ad4a07-000000@email.amazonses.com> <20190905.171730.1203130976409295649.mbj@tail-f.com> <20190905163216.GA3497@unix-ag.uni-kl.de>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/bJWRuTEhe8JPFhaLedWgrXAd3rA>
Subject: Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 07:25:19 -0000

Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
> Hi Martin,
> 
> On Thu, Sep 05, 2019 at 05:17:30PM +0200, Martin Bjorklund wrote:
> > Kent Watsen <kent+ietf@watsen.net> wrote:
> > > 
> > > >> There has been discussion about how embedding YANG models in RFCs seems like a
> > > >> poor fit for a number of reasons. By standardizing line-folding mechanisms and
> > > >> claiming them as a best practice, this document reinforces the root of that
> > > >> problem rather than trying to fix it.
> > > > 
> > > > Well said, I agree with Alissa's conclusion.
> > 
> > But the algorithm in the document isn't supposed to be used for YANG
> > modules.  It is supposed to be used primarily for XML and JSON
> > snippets (etc).
> 
> Technically, XML and JSON are whitespace-agnostic

Whitespaces are significant in XML element values, which means that we
have to write e.g.

    <discontinuity-time>2013-04-01T03:00:00+00:00</discontinuity-time>

With indentation for readability we quickly run out of horizontal
space.

> and often can be
> "folded" manually without any folding indicators.  That seems to be
> true for YANG as well.

It is true for YANG, which is why I wrote that this algorithm isn't
supposed to be used for YANG.  In fact, the document says:

   It is RECOMMENDED that authors do as much as possible within the
   selected format to avoid long lines.

> Even Python code usually can be kept under any
> reasonable line length.
> 
> Very long names or values could require algorithmic folding, i.e.,
> a generic line-folding mechanism.
> 
> I personally would try to keep the line length of any code inside an
> RFC short enough to not need additional algorithmic folding.  But if
> this does not work, e.g., because some name or value is just too long,
> having a recommended algorithm seems to be better than every author
> making up another ad-hoc folding scheme.
> 
> The I-D.ietf-netmod-artwork-folding seems to try to provide a recommended
> algorithm for the case where a generic line-folding mechanism is needed.

Exactly!


/martin


> 
> Overly long lines sometimes result in lost information in HTML or PDF
> documents, if a complex layout is used, but no mechanism for dealing with
> unexpectedly long lines is included.  I have seen too many examples of
> this to believe that this cannot happen with RFCs.
> 
> Thanks,
> Erik
>