On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder <[email protected]> writes: > > > Benoit, > > > > RFC 6020 is ambiguous and this is just how it is. The solution for > > YANG 1 is simply to give advice to module writers to avoid ambiguous > > character sequences (and avoiding ambiguity can be easily done). > > > > YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to > > YANG 1 is a change of YANG 1, i.e., it might turn a conforming > > implementation into a non-conforming implementation. Hence, this may > > go beyond the scope of an errata. > > But it is not really the case here because it cannot be decided what > conforming means. I chose YANG 1.1 behaviour for my JS parser, and I > don't think it is less conforming than any other.
Exactly. But other interpretations are legal as well. We can not retroactively turn so far conforming implementations of the RFC into non-conforming implementations (via an errata that introduces a MUST that was not there in the beginning). > This would be fine for the "Notes" part but RFC Errata require also > "Original Text" and "Corrected Text". Any suggestion for this? Corrected Text ------------- Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash: \n new line \t a tab character \" a double quote \\ a single backslash The interpretation of any other character then the ones listed above following a backslash is undefined. Authors are advised to avoid using such backslash sequences in double-quoted strings in their YANG modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
