Comments on the 1.1 Specification

[Michael Stevens <michael.j.stvns@gmail.com>]

Table 84: Usage Limits Attribute: multiple instances are not
permitted. This makes it impossible to place a limit on keys such as
"x bytes OR y messages, whichever comes first". I suggest it be made
clear that the usage limit is unique per kind of use limit, rather
than forcing only one kind of use limit per key.

3.31 Revocation Reason: Multiple instances are not permitted; This is
an issue, as cases may arise where a key is compromised on multiple
occasions, and an audit trail should be able to track all the
compromises

3.37 Contact Information: Multiple instances are not permitted.
However, it entirely conceivable that a managed object can have both a
primary and secondary contact. Is the intent that managed objects
should only ever have 1 contact, or that multiple contacts be placed
into a single string?

4.10 Check:
1) It seems this operation should be able to check the State of a
managed object, and refuse the use of a deactivated object.

2)"This operation SHOULD only be used when placed in a batched set of
operations...",
The standard should mention that it also requires the Batch Order
Option to be properly set (The operation is incoherent if the batch
processing is not ordered), and it's failure condition apparently
overrides the Batch Error Continuation Option.

3) According to L1373, a failure "does not return the Unique
Identifier" - This statement contradicts Table 151, which indicates
Unique Identifier is always required, even when returning a failed
Check.

6.3 Maximum Response Size
Firstly, there's clearly some sensible minimum for this value (Long
enough to handle the "Message too long error").
I suggest that such a minimum be called out explicitly within the
standard, instead of the current vague language.

Secondly, this creates some interesting issues with batched requests -
The error applies to the final message, but it is not, in general,
possible to determine the length of a response item before performing
the operation. This creates a unique case where a completed operation
may be obliged to return an error because of some *later* operation
pushing the total response length over the maximum size. Is this
intended behaviour?

-- Michael