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

From: Lou Berger <[email-masked]>
Date: Sun, 12 May 2019 17:19:44 -0400

All,

This starts a two-week working group last call for
draft-ietf-netmod-artwork-folding-02

The working group last call ends on May 27.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
NetMod Chairs

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 May 2019 22:41:39 +0100

Thanks Lou,

[speaking as an author]

This draft represents the coming together of two different approaches to the
same problem. The authors worked hard to merge and reach consensus, and the
current revision contains the product.

This document certainly addresses my personal requirement which is to
provide a common human-readable notation for use in XML examples in drafts
and RFCs so that artificial line-wraps can be disambiguated. And so I
support its publication.

Best,
Adrian

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Lou Berger
Sent: 12 May 2019 22:20
To: NetMod WG <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>
Subject: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

All,

Thank you,
NetMod Chairs

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 12 May 2019 15:40:13 -0700

Lou,

I support the progress of the draft and it is ready for the publication.

Regards,
Jeff

> On May 12, 2019, at 14:19, Lou Berger <[email-masked]> wrote:
> 
> 
> All,
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 May 2019 23:47:47 +0000

Since the response is tepid so far, and the request says "even from authors"...

    I've reviewed this document and believe it is ready for publication.

Kent // co-author

> On May 12, 2019, at 5:19 PM, Lou Berger <[email-masked]> wrote:
> 
> 
> All,
>

---

From: Italo Busi <[email-masked]>
Date: Fri, 24 May 2019 11:43:30 +0000

Hi all,

I have reviewed the document and I support its publication as an RFC

I have just few (related) minor comments which can be easily fixed during WG LC process

1) Section 7.2.1 (Folding for Single Backslash Strategy) says:

   Ensure that the desired maximum line length is not less than the
   minimum header, which is 46 characters.  If the desired maximum line
   length is less than this minimum, exit (this text-based content
   cannot be folded).

However, the first line defined in section 7.1.1 is a "45-character string".
I think that the paragraph be changed as:

   Ensure that the desired maximum line length is not less than the
   minimum header, which is 45 characters.  If the desired maximum line
   length is less than this minimum, exit (this text-based content
   cannot be folded).

2) Section 8.2.1 (Folding for Double Backslash Strategy) says:

   Ensure that the desired maximum line length is not less than the
   minimum header, which is 45 characters.  If the desired maximum line
   length is less than this minimum, exit (this text-based content
   cannot be folded).

However, the first line defined in section 8.1.1 is a "46-character string".
I think that the paragraph be changed as:

   Ensure that the desired maximum line length is not less than the
   minimum header, which is 46 characters.  If the desired maximum line
   length is less than this minimum, exit (this text-based content
   cannot be folded).

A question for clarification. Reading the following code in Appendix A:

     if [[ $strategy -eq 2 ]]; then
       min_supported=`expr ${#hdr_txt_2} + 8`
     else
       min_supported=`expr ${#hdr_txt_1} + 8`
     fi

It seems to me that the minimum lengths applied by the code in Appendix A are be 53 and 54 (instead of 45 and 46 respectively)

Is my understanding correct?

Thanks, Italo

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: domenica 12 maggio 2019 23:20
To: NetMod WG <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>
Subject: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

All,

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
NetMod Chairs

---

From: "Chongfeng Xie" <[email-masked]>
Date: Sun, 26 May 2019 09:52:09 +0800

Chongfeng

发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2019年5月13日 5:20
收件人: NetMod WG <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>
主题: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

All,

 
 
Thank you,
NetMod Chairs

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 May 2019 13:04:12 +0200 (CEST)

Hi,

I have reviewed draft-ietf-netmod-artwork-folding-02, and here are my
comments:

o  6

  Perhaps:

  OLD:

   begins at the first non-
   whitespace character on the following line.

  NEW:

   begins at the first character that is not a space character (' ')
   on the following line.

  The algorithm talks specifically about space (' ') rather than
  whitespace.

o  6.1

  s/is exists/exists/

o  6.1 / 6.2

  6.2 says (correctly!):

   It is RECOMMENDED for implementations to first attempt to fold
   content using the single backslash strategy and, only in the unlikely
   event that it cannot fold the input or the folding logic is unable to
   cope with a contingency occurring on the desired folding column, then
   fallback to the double backslash strategy.

  But 6.1 says about the Single Backslash Strategy:

   automation implementations are likely to encounter scenarios that
   will produce errors without special care

  So it 6.1 thinks it is likely that SBS won't work, but 6.2 says it
  is unlikely.  IMO 6.2 is correct - it is extremely unlikely that SBS
  won't work.

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.

  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.

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...)

o  7.2.1 / 7.2.2

  I don't think the text should assume that folding/unfolding is
  "automated".

o  7.2.1

  Perhaps add to bullet 1:

    If no such location can be found, then exit (this text content
    cannot be folded)

o  7.2.2

  s/maximum../maximum./

o  Appendix A

  Consider using the command "tempfile" instead of /tmp/wip*

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 May 2019 17:57:16 +0000

Hi Italo,

>   length is less than this minimum, exit (this text-based content

Fixed in my local copy.

>   length is less than this minimum, exit (this text-based content

Fixed in my local copy.

> Is my understanding correct?

The script is not conflicting with the draft, as it does ensure that the length is not less than the raw header text.  Though, to your point, it adds an additional buffer to further ensure that the header will always have some '=' characters wrapping around the header, for readability, in the unlikely scenario that such a narrow-width is needed.   I could go either way on this, does anyone else have an opinion?

> Thanks, Italo

Kent // author

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 May 2019 19:28:21 +0000

Hi Martin,

Thanks for your review.

>   begins at the first character that is not a space character (' ')

Updated in my local copy.

>  The algorithm talks specifically about space (' ') rather than

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?

>  s/is exists/exists/

Fixed.

>  is unlikely.  IMO 6.2 is correct - it is extremely unlikely that SBS

s/are likely to/may/

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.

>  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?

>  should be removed.  (I would even prefer less flexibility in the

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.

>  I don't think the text should assume that folding/unfolding is

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?

>    If no such location can be found, then exit (this text content

Added in my local copy.

>  s/maximum../maximum./

Fixed (in both locations)

>  Consider using the command "tempfile" instead of /tmp/wip*

Used `mktemp -d` instead.

Kent // author

---

From: Italo Busi <[email-masked]>
Date: Tue, 28 May 2019 13:33:31 +0000

Hi Kent,

Thanks for your reply

For what I am concerned, the clarification you have provided is sufficient to me (no need to change the code)

You might also consider adding similar text at the beginning of Appendix A, if you think this helps. Something along the line:

The script forces the desired maximum line length to be a bit longer than the raw header text defined in sections 7 and 8, to further ensure that the header will always have some '=' characters wrapping around the header, for readability, in the unlikely scenario that such a narrow-width is needed.

Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Kent Watsen [mailto:[email-masked]]
Sent: lunedì 27 maggio 2019 19:57
To: Italo Busi <[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

Hi Italo,

Fixed in my local copy.

Fixed in my local copy.

Thanks, Italo

Kent // author

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 28 May 2019 13:54:11 +0000

Hi,

I've read this document and have some minor comments on it. 

1) Abstract:
I wasn't sure whether the abstract is still entirely accurate, given that the document describes two strategies rather than one, only one of those strategies is time proven ('\'), and only one of those strategies works on *any* text-based content ('\\').

2) Section 4. Goals:
Is one of the goals to *exactly* reproduce the input text to the folding algorithm?  If so, this might be worth explicitly stating (e.g. because of the whitespace handling when using the single backslash strategy).

3) Section 5.1
Nit: will work -> works.

4) Section 5.2, 4th paragraph about functions.
I'm not sure this paragraph really adds anything to the document, so I would suggest removing it.  E.g. does this means that we should use YANG groupings to avoid line length indentation issues, if so, I would question whether that makes the resulting YANG model more readable.

5) Section 5.2, last paragraph.
I think that the RECOMMENDED is perhaps a bit strong, hence I would prefer "suggested" or "encouraged" over "RECOMMENDED".  I think that some/many of the input formats do have ways that the input can be modified such that folding isn't required, but I'm not sure that we necessarily advocate that should always be done.

6) 7.2.1. '\' folding algorithm:
It should also check if the line contains more than "max line length space" characters and if so it cannot be folded using this strategy.

7) 8.2.1. '\\' folding algorithm, 6th paragraph:
Does this have to abort if it finds a '\' character at the end of the line, and start at next?  I think that this could still be handled by folding again at that same point, which when unfolded should go back to the same input again.  Of course, such a tool might also warn that the input might already be folded input.  One of the advantages of the '\\' method is that it should be able to deterministically work on any input.

---

Final comment, and it is probably a bit late for this, but rather than having two separate schemes, I have one quick idea for merging the two.

The idea is this:  The principle difference between the two schemes is how they treat whitespace.  So, the suggestion is to make the '\' on the following line optional, so it is *only* used to separate insignificant whitespace from significant whitespace.  When unfolding, rather that only consuming leading whitespace following a fold, it would also optionally consume the '\' if it immediately followed the leading whitespace AND it also followed by a whitespace character.

Perhaps best illustrated with a short contrived example:

  "This is some example  text that I want to fold whilst preserving whitespace"

If I want to (approximately) fold this text around column 21, then I could fold it to this (using the existing '\' scheme):

"This is some \
 example  test that \
 I want to fold whilst \
 preserving whitespace"

Alternatively, I could fold the first line to this instead, separating significant whitespace from the insignificant whitespace:

"This is some example \
 \ text that I want to \
 fold, whilst preserving \
 whitespace"

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 May 2019 15:36:49 +0000

Hi Rob,

Thanks for your review.  Comments below.

> I wasn't sure whether the abstract is still entirely accurate, given that the document describes two strategies rather than one, only one of those strategies is time proven ('\'), and only one of t…

True, how about this (with a similar change in the Introduction)?

   This document defines two strategies for handling long lines in
   width-bounded text content.  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.  The second strategy
   extends the first strategy by adding a second backslash character to
   identify where the continuation begins and thereby able to handle
   cases not supported by the first strategy.  Both strategies use a
   self-describing header enabling automated reconstitution of the
   original content.

> Is one of the goals to *exactly* reproduce the input text to the folding algorithm?  If so, this might be worth explicitly stating (e.g. because of the whitespace handling when using the single bac…

This is what the second goal (4.2.) means by "reconstitution of the original text content".   The below is slightly modified, is it okay?

  4.2.  Automated Reconstitution of the Original Text Content

     Automated reconstitution of the original text content is needed to
     support validation of text-based content extracted from documents.

     For instance, already YANG [RFC7950] modules are extracted from
     Internet-Drafts and validated as part of the draft-submission
     process.  Additionally, the desire to validate instance examples
     (i.e., XML/JSON documents) contained within Internet-Drafts has
     been discussed ([yang-doctors-thread]).

Fixed.

> I'm not sure this paragraph really adds anything to the document, so I would suggest removing it.  E.g. does this means that we should use YANG groupings to avoid line length indentation issues, if…

Removed.  I agree that the (unfolded) YANG module's readability is more important and, besides, these are just examples and don't preclude anything.

> I think that the RECOMMENDED is perhaps a bit strong, hence I would prefer "suggested" or "encouraged" over "RECOMMENDED".  I think that some/many of the input formats do have ways that the input c…

Disagree.  We do want to advocate authors do what they can.  It was a SHOULD before, but downgraded to a RECOMMENDED to be less overt.

> It should also check if the line contains more than "max line length space" characters and if so it cannot be folded using this strategy.

You're correct that this is a problem case, but isn't it covered already by the following sentence?

   1.  Determine where the fold will occur.  This location MUST be
       before or at the desired maximum column, and MUST NOT be on top
       of a space (' ') character.  If no such location can be found,
       then exit (this text content cannot be folded)

> Does this have to abort if it finds a '\' character at the end of the line, and start at next?  I think that this could still be handled by folding again at that same point, which when unfolded sho…

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

> Final comment, and it is probably a bit late for this, but rather than having two separate schemes, I have one quick idea for merging the two.
<snip>

Yes, too late for that kind of change I think, at least I'm not interested in investing the time to see if its viable.

Kent // author

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 28 May 2019 16:02:55 +0000

Hi Kent,

Please see inline ...

From: Kent Watsen <[email-masked]>
Sent: 28 May 2019 16:37
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

Hi Rob,

1) Abstract:

[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.

2) Section 4. Goals:

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

3) Section 5.1
Nit: will work -> works.

Fixed.

Disagree.  We do want to advocate authors do what they can.  It was a SHOULD before, but downgraded to a RECOMMENDED to be less overt.
[RW]
According to RFC2119, RECOMMENDED is interpreted exactly the same way as SHOULD.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I still think that SHOULD/RECOMMENDED is too strong.

[RW]
Yes, thanks for the clarification.

   <snip>

[RW]
OK.

[RW]
OK.

Thanks,
Rob

Kent // author

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 May 2019 16:36:51 +0000

Hi Italo,

Thank you for the text suggestion, I landed on the following text:

   For readability purposes, this script forces the minimally supported
   line length to be eight characters longer than the raw header text
   defined in Section 7.1.1 and Section 8.1.1 so as to ensure that the
   header can be wrapped by a space (' ') character and three equal
   ('=') characters on each side of the raw header text.

Kent // author

> On May 28, 2019, at 9:33 AM, Italo Busi <[email-masked]> wrote:
> 
> Hi Kent, <>
>  
> Thanks for your reply
>  
> Email : [email-masked] <mailto:[email-masked]>
>  
> From: Kent Watsen [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Italo Busi <[email-masked] <mailto:[email-masked]>>
> Cc: Lou Berger <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 May 2019 16:53:07 +0000

> 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.

> 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?

>    exceeds the desired maximum, or requires a forced folding, then fold

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 28 May 2019 17:31:35 +0000

Sent: 28 May 2019 17:53

[RW]

Would s/time-proven/POSIX/ be better?
[RW]
Perhaps, less is more, e.g.,

“One strategy is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred.”?

[RW]
OK.

[RW]

[RW]

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.
[RW]
Er, I strongly disagree that RECOMMENDED has any different semantic meaning to SHOULD.  RFC 2119 is explicit that they mean exactly the same thing.  If you want it to be softer, then perhaps change it to “recommended” which I do think is softer than “should”. 😊

[RW]
So, for example considering the current text, if it was a JSON input file, it would be more appropriate to change the indentation level to 2 spaces rather than 4 spaces to ensure that there are not unnecessary line wraps?  In theory, the only place in a JSON file that we would expect there to be a line breaks would be within a string because that is the only case that can’t be handled within JSON itself.

Is this your intended meaning?

   <snip>

[RW]
OK.

[RW]
Sure.

Thanks,
Rob

Kent // author

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 May 2019 19:20:07 +0000

> “One strategy is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred.”?

Replaced.

> Is this your intended meaning?

Certainly one example, yes.

Kent // author

---

From: Italo Busi <[email-masked]>
Date: Wed, 29 May 2019 13:02:02 +0000

It looks very good to me

Thanks, Italo

Italo Busi

Sent: martedì 28 maggio 2019 18:37

Hi Italo,

Kent // author

On May 28, 2019, at 9:33 AM, Italo Busi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Thanks for your reply

Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]<mailto:[email-masked]>

From: Kent Watsen [mailto:[email-masked]]
Sent: lunedì 27 maggio 2019 19:57
To: Italo Busi <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

Hi Italo,

Fixed in my local copy.

Fixed in my local copy.

Thanks, Italo

Kent // author

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 May 2019 15:15:56 +0200 (CEST)

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

If you write POSIX I think you need a reference.  Is there really a
POSIX standard for how a single backslash is used...?

I think "time-proven" is better.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 May 2019 15:33:59 +0200 (CEST)

> > I have reviewed draft-ietf-netmod-artwork-folding-02, and here are my

[...]

> 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.

[...]

>    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.

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.

> 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.

> 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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 May 2019 23:41:59 +0000

Hi Martin,

> about how the author decides to implement this format.

removed the word "assumed", now text reads:

   When a larger document contains multiple instances of text content
   that may need to be folded or unfolded, another process must insert/
   extract 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.

> I would just remove this paragraph.

This paragraph and others like it were added by others that thought that this algorithm was intended to process an entire I-D or RFC.

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

Okay, not changed.

> IMO we could remove this arbitrary limitaion and still leave the

Not arbitrary, as explained, leaving as is.

>   Determine the desired maximum line length from input to the

Fixed (in 8.2.1 also)

You supplied text for 7.2.1, but also mentioned 7.2.2 (and ~ 8.2.2) originally.   For these sections, the appropriate change is to remove the first paragraph, which I did (in my local copy).   Specifically:

OLD:

   All unfolding is assumed to be automated although a reader will
   mentally perform the act of unfolding the text to understand the true
   nature of the original text content.

NEW:

    <deleted>

Kent // author

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 May 2019 23:01:09 -0400

All,

     The WG LC is closed.

Authors,

     Please continue resolving the raised issues on the list, and let 
the WG know once a version that addresses all raised issues has been 
uploaded/published.  Also please also summarize any includes changes 
that were not otherwise discussed on-list.

Thank you!

Lou