The main concern is an embedded NUL terminator in a string.
It already happened that (by accident, bug in length calculation) encoded strings contained the terminating \0 at the end. This caused problems because different vendors seem to handle such content differently. Sometimes an error is generated, sometimes the string is trimmed to the first \0, sometimes it is forwarded without alteration or notice.
Embedded \0 in strings are a problem in other encodings, like XML, too. This means, forwarding values or messages over multiple connections using different encodings is likely to fail. Sometimes escaping those characters may be an option, sometimes not. but encoders must be prepared for this, if required.
Therefore, the definition of valid characters in a string and the reaction to invalid characters should be precise, without may and shall, if possible.
The use of ByteString is an alternative when special characters are required.

There is zero chance that a string with a null character in the middle of a string would be handled right if you process it in different layers with different protocols and different applications.

There is no practical use case for it but it would create endless work to handle it right in a lot of implementations.

We should simply explicitly disallow NULL in a string.
This is not a Part 6 issue, this is a Part 3 issue!

Added:

Strings with embedded nulls (‘\u0000’) are not guaranteed to be interoperable because not all DevelopmentPlatforms will be able to handle Strings with embedded nulls. Encoders may encode Strings with embedded nulls. Decoders may truncate the String at the first embedded null before passing it on to the application.

in OPC 10000-6 - UA Specification Part 6 - Mappings 1.05.3 RC

Reviewed in WG - need to review version table text.

Agreed to final change to table text.

Agree to changes