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
> -----Original Message-----
> From: netmod <[email protected]> On Behalf Of Lou Berger
> Sent: 12 May 2019 22:20
> To: NetMod WG <[email protected]>
> Cc: NetMod WG Chairs <[email protected]>
> Subject: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
>
>
> 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
>
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
