[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on the 1.1 Specification
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]