View Issue Details

IDProjectCategoryView StatusLast Update
000922610000-006: MappingsSpecpublic2023-12-04 19:46
ReporterKevin Herron (Inductive Automation) Assigned ToRandy Armstrong  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Fixed in Version1.05.03 
Summary0009226: OPC UA 1.05 introduced interoperability issues in binary String encoding
Description

In OPC UA 1.04, it was very explicit that Strings are not null-terminated:

All String values are encoded as a sequence of UTF-8 characters without a null terminator and
preceded by the length in bytes.

In OPC UA 1.05 the waters have been muddied and now additional behavior that is "not guaranteed to be interoperable" has been allowed:

Strings with embedded nulls (‘\0’) are not guaranteed to be interoperable because not all DevelopmentPlatforms can handle Strings with embedded nulls. For this reason, embedded nulls are not recommended. Encoders may encode Strings with embedded nulls. Decoders shall use the length to read all bytes in String, however decoders may truncate the String at the first embedded null before passing it on to the application.

I cannot wrap my head around this decision. Now my stack, which decodes Strings to spec as of 1.04, suddenly looks like the broken one when some other server out there is using null-terminators in Strings as if they are significant. To make matters worse, UaExpert, or the underlying stack, truncates Strings at the first null byte, which further complicates the issue because now everyone thinks null terminators are significant and that's the correct behavior.

TagsNo tags attached.
Commit Version1.05.03
Fix Due Date2023-10-15

Activities

David Levine

2023-11-07 14:49

developer   ~0020281

String termination has been a problem for a long time. I agree with Kevin that the 1.04 wording provides a better guarantee of interoperability, as all characters are significant.
RA PLCs support embedded nulls, so we need this.

IMO encoders/decoders at the lowest level shall use the preceding length and ignore embedded nulls. If a platform uses nulls as terminators (C style strings), it should be done at the interface between the stack and the app, or entirely within the app level itself for both clients and servers.

It might make sense to add a ServerCapability node that indicates if a server supports embedded nulls, so clients have the opportunity to adjust their behavior. The default should be that the server supports embedded nulls, since that was previously required.

Randy Armstrong

2023-12-04 19:45

administrator   ~0020482

Updated 5.2.2.4 String

Strings with embedded nulls (‘\0’) can lead to unpredictable application behaviour because embedded nulls have special meaning to some DevelopmentPlatforms. For this reason, embedded nulls are not recommended and ByteString should be used instead. That said, Encoders may encode Strings with embedded nulls. Decoders shall use the length to read all bytes in String.

Jim Luth

2023-12-04 19:46

administrator   ~0020483

Agreed to new text edited in virtual F2F.

Issue History

Date Modified Username Field Change
2023-11-01 16:53 Kevin Herron (Inductive Automation) New Issue
2023-11-07 14:49 David Levine Note Added: 0020281
2023-11-07 17:56 Jim Luth Assigned To => Randy Armstrong
2023-11-07 17:56 Jim Luth Status new => assigned
2023-11-07 17:57 Jim Luth Commit Version => 1.05.03
2023-11-07 17:57 Jim Luth Fix Due Date => 2023-10-15
2023-12-04 19:45 Randy Armstrong Status assigned => resolved
2023-12-04 19:45 Randy Armstrong Resolution open => fixed
2023-12-04 19:45 Randy Armstrong Note Added: 0020482
2023-12-04 19:46 Jim Luth Status resolved => closed
2023-12-04 19:46 Jim Luth Fixed in Version => 1.05.03
2023-12-04 19:46 Jim Luth Note Added: 0020483