Issue raised by: Johan Cornels Zeeman Fri, 10 Jul 1998 12:36:19 -0400
It appears syntactically valid to send a scan request that does not include an attribute set id.
(The attribute set id is optional within the Scan APDU as it may alternatively be provided within termListandStartPoint, which is of type AttributesPlusTerm, which includes AttributeList, which provides for an attribute set id to be included for every attribute type/value pair. But those attribute set ids are also optional. Therefore it is possible to construct a syntactically correct Scan APDU where one or more attribute type/value pairs remains unqualified by attribute set id).
This seems clearly invalid, since the semantics of the attributes depend on the attribute set id. There are, however, no procedural rules specifying behaviour in the absence of an attribute set id. It seems that this should be treated as a protocol error, or at least there should be an explicit diagnostic for this condition.
It is indeed clearly invalid though syntactically correct, not to supply an attribute set id.
The attribute set id parameter in the Scan APDU is optional because of the possibility that an attribute set id might be attached to every attribute pair. However, this is the only valid condition under which the attribute set id parameter may be omitted. No attribute pair should remain unqualified by attribute set id.
If a Scan request is sent where one or more attribute pairs remains unqualified (that is, where the attribute set id parameter is omitted in the Scan request and is also omitted for one or more attribute pairs) the server should treat this condition as an error. The server, at its discretion, may treat this either as a protocol error or may fail the Scan and return a diagnostic. Diagnostic 1051: " Scan: Attribute set id required -- not supplied" has been defined for this condition.