On Wed, Nov 16, 2016 at 12:38:49PM +0100, Marco d'Itri wrote: > On Nov 16, Julian Seifert <[email protected]> wrote: > > I agree with both points. Maybe not use utf8/unicode or reduce to > > only alphanumerics? > > Not supporting UTF-8 is not acceptable for a new IETF protocol and > would preclude using it in some cultures. > > Customers with really crappy management infrastructure could ask their > vendors to implement a knob to report the strings as base64, but I > really wonder which real world use cases there are for this.
Yes, I can't imagine folks using Cyrillic or Kanji for their daily communication to be happy if the Shutdown Communication only allows use of Latin characters. Unless some implementors make significant arguments along the lines of "we CANNOT implement this Shutdown Communication functionality, SOLELY because of utf8 and lack of representation filtering capabilities", i'd water down the utf8 requirement to 7bit ascii (because in the end its better to have 'something' than nothing). Another line of argumentation against utf8 would be if major security concerns are articulated. I hope to capture in the draft that an implementation can choose which characters of the Shutdown Communication they represent in the syslog or 'show bgp neighbor xxx' output. For instance, I'd recommend to squash all newline/newpage/newfeed/newparagraph style chars and make sure that the Communication is represented on a single line. I don't have the proper words for the draft to express that (yet). Also I don't mind if an implementation consciously chooses to only represent 7bit ASCII. That should be an implementor decision. They can upgrade later. In theory the protocol spec shouldn't be delayed or obstructed due to an implementor's current internationalisation capabilities (which can change over time). Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
