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

Kent Watsen <kent@watsen.net> Tue, 28 May 2019 16:53 UTC

Return-Path: <0100016aff5c1a19-32fa804b-b9d4-4411-a350-0a5571256e10-000000@amazonses.watsen.net>
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 C4861120198; Tue, 28 May 2019 09:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 cHU_pBQP6g-d; Tue, 28 May 2019 09:53:08 -0700 (PDT)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9220E120167; Tue, 28 May 2019 09:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1559062387; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=GR8gAPMYwfn/4q14b7OkVkmuPSE43LtWkn+7dHchDjk=; b=XTlPd0c5yS2NgMWjO/t+1ep3GSvbSMtC0/Yq3t2OfqGFQJaXBNZxaC4l2tze0RRJ KgG3h3Z0ZTjRvhCM6Mh5YWc4TjRYHloRxJRy27qqiGsD2QUDjNqd7sPxHY/exOl1Lik dOcwHZmtNY6WUcY/pqYwAebgj7ToMSkLQhwlQ0tA=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016aff5c1a19-32fa804b-b9d4-4411-a350-0a5571256e10-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2AFD125B-9A20-44BE-B55C-940090CA244F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 28 May 2019 16:53:07 +0000
In-Reply-To: <BYAPR11MB263191E71A0E09CE1667AB45B51E0@BYAPR11MB2631.namprd11.prod.outlook.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-artwork-folding@ietf.org" <draft-ietf-netmod-artwork-folding@ietf.org>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <e6fc4541-891a-60cb-e956-86f238d09f14@labn.net> <BYAPR11MB263112EA231A41491AC4DF89B51E0@BYAPR11MB2631.namprd11.prod.outlook.com> <0100016aff1640f0-a301a70e-ecae-4754-84d1-12170d5b73fd-000000@email.amazonses.com> <BYAPR11MB263191E71A0E09CE1667AB45B51E0@BYAPR11MB2631.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.05.28-54.240.8.64
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/5p4ANBWj7pBTo2hK3jw1jRboEVk>
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: Tue, 28 May 2019 16:53:11 -0000


> [RW] 
> Yes, I think that is better, and probably OK.
>  
> I still slightly question “One strategy is based on the time-proven use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first non-space (' ') character on the next line.”  Because I don’t think that is how ‘\’ character works, at least in languages such as C.  Specifically, it doesn’t ignore leading whitespace on the following line, instead it is often used where that whitespace is not significant to the compiler.

Would s/time-proven/POSIX/ be better?

BTW, I also added this to Appendix A:

   Shell-level end-of-line backslash ('\') characters have been
   purposely added to the script so as to ensure that the script is
   itself not folded in this document, thus simplify the ability to
   copy/paste the script for local use.  As should be evident by the
   lack of the mandatory header described in Section 7.1.1, these
   backslashes do not designate a folded line, such as described in
   Section 7.




> [RW] 
> Perhaps “original text content” -> “exact original text content”?  But I’m also OK with your suggested text.

I'm hesitant, because it seems redundant, but it doesn't cause harm, so I added it.



> [RW] 
> According to RFC2119, RECOMMENDED is interpreted exactly the same way as SHOULD.

Yes, when composing my response before I was going to say that it's a downgrade "(in IMO)", but figured it would require more explanation, which I was hoping to avoid.  But here we are now  ;)   While I'm aware that they carry the same RFC 2119 weight, RECOMMENDED reads softer to me, less commanding, hence my comment.



>  I still think that SHOULD/RECOMMENDED is too strong.

I still disagree.    Any tie-breakers out there?



> Good point, how about this?
>  
>    Scan the text content to ensure no existing lines already end with a
>    backslash ('\') character while the subsequent line starts with a
>    backslash ('\') character as the first non-space (' ') character, as
>    this could lead to an ambiguous result.  If such a line is found, and
>    its width is less than the desired maximum, then it SHOULD be flagged
>    for forced folding (folding even though unnecessary).  If the folding
>    implementation doesn't support forced foldings, it MUST exit.
>  
>    <snip>
>  
>    For each line in the text content, from top-to-bottom, if the line
>    exceeds the desired maximum, or requires a forced folding, then fold
>    the line by:
>  
>  
> [RW] 
> OK.

Great.  BTW, I also added this to Appendix A:

   This script does not implement the "forced folding" logic described
   in Section 8.2.1.  In such cases the script will exit with the
   message:

         Error: infile has a line ending with a '\\' character
         followed by a '\\' character as the first non-space
         character on the next line.  This file cannot be folded.




Kent // author