Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

Martin Bjorklund <mbj@tail-f.com> Wed, 29 May 2019 13:34 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 84E30120130; Wed, 29 May 2019 06:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Qo1y_pSk7uFB; Wed, 29 May 2019 06:34:01 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D89E912011A; Wed, 29 May 2019 06:34:00 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 23C1E1AE0428; Wed, 29 May 2019 15:33:59 +0200 (CEST)
Date: Wed, 29 May 2019 15:33:59 +0200 (CEST)
Message-Id: <20190529.153359.2174895235346852569.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016afac3dceb-3efc8938-6954-48c7-a362-e92c08400df0-000000@email.amazonses.com>
References: <e6fc4541-891a-60cb-e956-86f238d09f14@labn.net> <20190527.130412.1876961670794351457.mbj@tail-f.com> <0100016afac3dceb-3efc8938-6954-48c7-a362-e92c08400df0-000000@email.amazonses.com>
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/mMGj8fgBbwtDOiurwTbT0ZVIs48>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
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: Wed, 29 May 2019 13:34:03 -0000

Kent Watsen <kent+ietf@watsen.net>; wrote:
> 
> 
> Hi Martin,
> 
> Thanks for your review.
> 
> 
> > I have reviewed draft-ietf-netmod-artwork-folding-02, and here are my
> > comments:

[...]

> >  The algorithm talks specifically about space (' ') rather than
> >  whitespace.
> 
> True and, FWIW, this was the only instance of the word "whitespace" in
> the document.
> 
> However, I wonder if there might be an issue lurking here.  Already
> the algorithm eliminates the potential for TAB, and implicitly
> eliminates NL and CR through the use of the word "line", but I wonder
> if there are other characters that we wish to skip
> over... e.g. vertical tab?

No.

[...]

> > o  7.1.2 / 7.2
> > 
> >  I would prefer if the format is defined with descriptive text,
> >  rather than with an algorithm.  It is the end result that matters,
> >  not which algorithm an implementation uses to get to the result.
> > 
> >  I suggest the algorithm is moved to an appendix, and/or a sentence
> >  is added that explains that the algorithm is just an example.
> 
> OLD:
> 
>    This section describes the process for folding and unfolding long
>    lines when they are encountered in a single instance of text content.
>    It is assumed that another process inserts/extracts the individual
>    text content instances to/from an Internet-Draft or RFC.  For
>    example, the `xiax` utility [xiax] does this.
> 
> 
> NEW:
> 
>    This section describes a process for folding and unfolding long lines
>    when they are encountered in text content.
> 
>    The steps are complete, but implementations MAY achieve the same
>    result in other ways.
> 
>    When a larger document contains multiple instances of text content
>    that may need to be folded or unfolded, it is assumed that another
>    process inserts/extracts the individual text content instances to/
>    from the larger document prior to utilizing the algorithms described
>    in this section.  For example, the `xiax` utility [xiax] does this.

Well, again I don't really understand why we need to assume _anything_
about how the author decides to implement this format.

I would just remove this paragraph.

> >  Also expand the descriptive text in 7.1.2; I think that the text in
> >  section 6 is probably enough.  However, there are some important
> >  details buried in the desciption of the algorithm; specifically the
> >  cases where SBS can't be used.
> 
> I looked at this for a little while, but didn't see how it could be
> improved.  Can you provide some text?


NEW:

   Lines that have a backslash ('\') occurring as the last character in
   a line are considered "folded", which means that the line continues
   at the first character that is not a space (' ') on the following line.

   Really long lines may be folded multiple times.


On second thought, this text doesn't have to mention when SBS can't be
used.


> > o  7.2.1
> > 
> >  I don't understand why there is a min limit of 46 characters for
> >  folding to work.  If the only reason is for the non-normative script
> >  to be able to center the header line, then I think this limitation
> >  should be removed.  (I would even prefer less flexibility in the
> >  header line syntax...)
> 
> This is because we never defined how to handle folding the header
> itself.  I wrote about this a while back and no-one seemed bothered by
> the limitation.  The effort/value ration isn't there.  The need to
> fold less than 69-characters is unlikely, and less than 46-characters
> seems even more so.

IMO we could remove this arbitrary limitaion and still leave the
header alone.

> > o  7.2.1 / 7.2.2
> > 
> >  I don't think the text should assume that folding/unfolding is
> >  "automated".
> 
> Both sections clearly state that authors may do the equivalent
> manually, or do you mean that the word "automated" in these sections
> isn't adding much value and could/should be removed?

Right:

OLD:

   Folding is assumed to be automated although authors may perform the
   folding steps manually.

   Determine the desired maximum line length from input to the automated
   line-wrapping process,

NEW:

   Determine the desired maximum line length from input to the
   line-wrapping process,




/martin