We are moving to a policy of always including the prefix 0: in specs to make it really obvious what is intended.

The concept of "define a name but not the namespace" does not exist in OPC UA. There may be rare examples but they have to explicitly call that out. If the spec is silent then BrowseName defined always means fixed Namespace.

https://mantis.opcfoundation.o.....p?id=11508

What the first connection with the DCA should use an IDevID as a client cert and the Registrar should accept it as untrusted.

i.e. authenticated but without trust.

The next steps establish trust.

Needs a mantis issue against Part21: 

https://mantis.opcfoundation.o.....default=no

I am reading OPC-10000-21 V1.05.04.

Section "7.1 - Overview" states:

"When using PullManagement (7.2) the DCA connects to the Registrar without security and calls the ProvideIdentities Method."

In section "7.2 Pull Management", the flow chart diagram in "Figure 4" makes it seem like "ProvideIdentities" is indeed called without security and the "Create SecureChannel" occurs at a later time.

However, section "9.2.3 ProvideIdentities" states:

"This Method shall be called from an authenticated SecureChannel."

Am I overlooking something or is this an inconsistency in the specification?

For "0:NodeVersion" (https://reference.opcfoundatio.....-40540/6.3) this rule is explicitly mentioned in the spec, should this also be changed to explicit "0:FileSystem" (https://reference.opcfoundatio.....0-20/4.3.2) to avoid confusion?

And for the BrowseName under the Objects (i=85) folder: Should we use 0:FileSystem or <instanceNs>:FileSystem (e.g. 5:FileSystem, when 5 is our FileSystem namespace)?

Clients can only detect if a Server supports the File Transfer - File System Spec by browsing the Objects-Folder (i=85) and filtering for *:FileSystem results, right?

Need to add IsDesignTool which will make it clear why it is not referenced.

You should never use i=16314

when to use the FileSystem NodeId i=16314 for a FileSystem instance? Is it reserved for FileSystem instances referenced directly under the Objects (i=85) folder?

The spec says, that the BrowseName has to match "<ns>:FileSystem" (not even restricts it to "0:FileSystem") but it does not define the standard NodeId (i=16314):

The Object representing the root of a file directory structure shall have the BrowseName FileSystem. An OPC UA Server may have different FileSystem Objects in the AddressSpace. HasComponent is used to reference a FileSystem from aggregating Objects like the Objects Folder or the Object representing a device.

The Opc.Ua.NodeSet2.xml contains this NodeId, but is not referenced:

<UAObject NodeId="i=16314" BrowseName="FileSystem">

Best regards,

Thomas

we would need to check the details of the certification as well as the behavior to see whether there was a gap in testing which caused this to be missed or whether this is actually compliant behavior under the given circumstances.

Since we would not like to discuss this in public, can you please send a mail to compliance@opcfoundation.org with further details about the product, the version you are using and in which scenario you are experiencing the issue?

We will then investigate and get back to you via e-mail. If we find something missing in the testing we will then create additional test cases to cover those cases and make sure these are caught in the future.

Regards,
Alexander Allmendinger

A follow up question on ConditionName.

We have observed OPC UA servers that provide an empty or null ConditionName, while at the same time holding OPC Foundation certification. 

Given that the confirmation that ConditionName must not be null or empty, we are trying to understand how such a server could still pass conformance testing. Is ConditionName perhaps covered by a different Facet or Profile than those included in the server's certification (see below)? Or is the value simply not validated as part of the relevant conformance test cases?

It would be useful to understand whether this behavior is outside the scope of the certification tests, whether there is an interpretation issue regarding the specification requirements, or whether there is a gap in the current test coverage.

Any clarification on how ConditionName is evaluated during OPC Foundation certification would be greatly appreciated.

The A&C facet that the OPC UA servers holding OPC Foundation certification on are:

- A&C Base Condition Server Facet
- A&C Acknowledgeable Alarm Server Facet

Thanks

ConditionName identifies the Condition instance that the Event originated from. It can be used together with the SourceName in a user display to distinguish between different Condition instances. If a ConditionSource has only one instance of a ConditionType, and the Server has no instance name, the Server shall supply the name element of the BrowseName of the ConditionType.

Specification says no and provides a default if it does not make sense.

Another question in same area. 

Is it allow to set property ConditionName (in EventType ConditionType) to null or empty according to the OPC UA specifications. 

Thanks