Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

Martin Bjorklund <mbj@tail-f.com> Tue, 26 June 2018 10:26 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 5D3EF130FCF for <netmod@ietfa.amsl.com>; Tue, 26 Jun 2018 03:26:13 -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_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 zprb_5AMr8bS for <netmod@ietfa.amsl.com>; Tue, 26 Jun 2018 03:26:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D853B130FC1 for <netmod@ietf.org>; Tue, 26 Jun 2018 03:26:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 0AA2E1AE0311; Tue, 26 Jun 2018 12:26:02 +0200 (CEST)
Date: Tue, 26 Jun 2018 12:26:02 +0200
Message-Id: <20180626.122602.1952551623315308243.mbj@tail-f.com>
To: bill.wu@huawei.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AEB4274@nkgeml513-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9AEB4274@nkgeml513-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/AnHdOVxUjSqoSCjIqVHZnsaLI3k>
Subject: Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 26 Jun 2018 10:26:14 -0000

Hi,

I support this work.   See below for some comments.

Qin Wu <bill.wu@huawei.com> wrote:
> Dear WG,
> 
> As you may recall I presented yang-xml-doc-conventions in London.
> There was strong support for trying to solve the problem and mixed
> views on the solution, other than that we should do it fast.  In the
> meanwhile, Kent submitted artwork-folding as an alternative solution.
> 
> The authors of the two drafts decided to combine efforts.  After
> several internal iterations on both drafts, the drafts were becoming
> more alike than different(both support auto wrapping or auto folding).
> The artwork-folding draft was selected as a preferred offering basis
> (i.e., draft-kwatsen-netmod-artwork-folding-04) to the working group
> to consider for adoption.
> 
> The primary feature differences remained are:
>   - all folded lines continue of column 0 without two character
>     indentation, i.e., whether auto indentation should be supported.

I really liked the flexible indentation in the other draft.  I suggest
it is added to this draft.  It enhances readability (if the author
wants it).

>   - handle two special case on backslash and space at the end of broken
>     line in yang-xml-doc-conventions.
>   - propose to use <WRAPPED TEXT BEGIN><WRAPPED TEXT END> to extract
>     artwork from I-Ds.

The artwork draft proposes only a header, which means that it is not
quite clear where the artwork ends.

In the artwork draft, section 5.3, you write:

   This line is self-describing in
   three ways: use of '\' character, identification of BCP/RFC, and
   identification of what the maximum line length is for the artwork.

I was confused about this maximum line length; it seems you define the
maximum line length ot be 53, but that seems too limiting, and indeed
in the example in 5.4 the max line length is 69.  (BTW, the example is
missing in the draft, as is the shell script in Appendix A).   In any
case, I don't see how the header identifies the max line length.

Also, in section 5.2, the first sentence is:

  Scan the artwork to see if any line exceeds the desired maximum.

But what is the desired maximum?   I assume that the idea is that the
author first selects a desired max?  Maybe add a line that explains
this, and again write that 69 is a reasonable value for use in I-Ds
and RFCs.


/martin




> 
> Thanks,
> Qin, Kent, Benoit and Adrian
> -----邮件原件-----
> 发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> 发送时间: 2018年6月23日 9:33
> 收件人: Benoit Claise; Qin Wu; Kent Watsen; Adrian Farrel; Benoît
> Claise
> 主题: New Version Notification for
> draft-kwatsen-netmod-artwork-folding-04.txt
> 
> 
> A new version of I-D, draft-kwatsen-netmod-artwork-folding-04.txt
> has been successfully submitted by Qin Wu and posted to the IETF
> repository.
> 
> Name:		draft-kwatsen-netmod-artwork-folding
> Revision:	04
> Title:		Handling Long Lines in Artwork in Drafts
> Document date:	2018-06-22
> Group:		Individual Submission
> Pages:		9
> URL:
> https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-artwork-folding-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-folding/
> Htmlized:
> https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-04
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kwatsen-netmod-artwork-folding
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-artwork-folding-04
> 
> Abstract:
>    This document introduces a simple and yet time-proven strategy for
>    handling long lines in artwork in drafts using a backslash ('\')
>    character where line-folding has occurred.  The strategy works on any
>    text based artwork, producing consistent results regardless the
>    artwork content.  Using a per-artwork header, the strategy is both
>    self-documenting and enables automated reconstitution of the original
>    artwork.
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod