Log In
Home
04/09/2014
Offline
I have two questions about the correct application behavior for attribute read requests.
i) our client tries to retrieve a certain set of attributes for the results of each browse request. Since we do not know the node classes (*) of the nodes and we don't want to issue two read requests, the set of attributes is chosen in a way that some nodes may not support some of the attributes. In this case I'm used to receive a BadAttributeIdInvalid service result exception for the pertinent attributes, which I can match against the (now known) node class and react accordingly. Now we encountered a server which reacts with a BadUnsupported exception in this case. Is this a valid way to respond to such a request and, if not, how should the client react? Apart from that I wonder whether our request to the server is actually allowed (i.e. to simply ask for attributes without knowing whether they are supported and expect a certain exception if not).
ii) some attributes are optional for certain node classes, like the 'Description' attribute, while being a valid attribute. For this I also noted that some servers return a BadAttributeIdInvalid service result when they do not support it. Assuming this exception is correct in the situation described in i) I'm wondering whether it is also adequate in this second case.
Thank you in advance for any reply.
Thomas
(*) this is, strictly speaking, not correctly described. The node class is a return parameter in the ReferenceDescription in the result of the browse request. We encountered, however, cases, where the node class we got back was incorrect, which resulted in weird errors. In part IV of the spec a footnote in Table 167 seems to say that this is actually allowed under certain circumstances. For this reason I do not trust the value of the node class attribute in the browse response, esp. since in the example we came across the 'circumstances' were not given (if I recall correctly...).
Moderators-Companion
02/24/2014
Offline
Hi Thomas,
The correct StatusCode for both cases is Bad_AttributeIdInvalid = "The attribute is not supported for the specified node". This is the only matching operation level StatusCode that is listed for the Read service. It applies to attributes not defined for a NodeClass but also to not supported optional attributes.
It is allowed to return other generic status codes for generic error scenarios like Bad_OutOfMemory but a server must return a specific code from the service definition if a specific code is listed there. And Bad_AttributeIdInvalid is the specific error code listed for the Read service for the case that an attribute is not supported for a node.
From Part 4 - 5.3 Service Results:
"The Services define various specific StatusCodes and a Server shall use these specific StatusCodes as described in the Service. A Client should be able to handle these Service specific StatusCodes. In addition, a Client shall expect other common StatusCodes defined in Table 177 and Table 178."
This also implies that a client need to be able to deal with all kind of error codes.
As a side note:
A server that does not return the correct NodeClass in the Browse result is not a compliant server. I would not trust such a server as a client and working around such a non compliant servers with a strange client behavior is not a good idea. It puts unnecessary load to compliant servers and guessing the NodeClass by the returned attributes is also not a good idea. Servers may restrict access to attributes based on the user logged in to the session. The only reliable information is the NodeClass returned in Browse and Read.
The only case where the server is allowed to not return the NodeClass is the case of an off server reference. But in this case you cannot read the attributes from the connected server since the node is in another server and reading the attributes requires a connect to this other server.
Matthias
1 Guest(s)
Usage Policy