kmip-interop-tech — archive

[John Leiseboer]

Tim said: > Like many things within KMIP you have to follow the underlying model... And of course there is no model specified, so it all comes down to interpretation. So let's look at a couple of scenarios that I hope bring this all down to the essence of the issue at hand: priority order, or precedence rules, for Template-defined vs request-defined attribute values. In the interests of reducing "noise", I'm not going to use the XML form here, but something that I hope is clear, while being more compact. First, we register a template that has a name, and two other attributes. One is multi-instance, the other is single instance. Template: Name="TC-312-12-Template" x-ID="from template" Contact Information="Joe (from template)" Second, we perform a Create operation. This operation references the Template, and defines two attributes. One attribute is the same multi-instance attribute as in the Template (with a different value). The other attribute is the same single-instance attribute as in the Template (with a different value). Create Request: Name="TC-312-12-Template" x-ID="from request" Contact Information="Jim (from request)" Here are two possible responses to a Get Attributes request for the resulting object: Get Attributes response (option 1): x-ID[0]="from template" x-ID[1]="from request" Contact Information[0]="Jim (from request)" Get Attributes response (option 2): x-ID[0]="from request" x-ID[1]="from template" Contact Information[0]="Jim (from request)" Option 1 is most similar to the response given in TC-312-12, and the "KMIP model" that I think Tim has in his mind; i.e. x-ID from the template has index 0 because it appears first in the request message. Option 2 is most similar to the response you would get from a QuintessenceLabs server. Option 1 logic: x-ID from the template gets index 0 because the template is processed before the request attributes. Contact Information from the request is assigned because the standard says that request-defined single-instance attribute values take precedence over Template-defined attribute values. If you were to watch the attribute values being created within a server following Option 1's logic, you might see something like this: Time 1 x-ID[0]="from template" Time 2 x-ID[0]="from template" Contact Information[0]="Jim (from template)" Time 3 x-ID[0]="from template" Contact Information[0]="Jim (from template)" x-ID[1]="from request" -- assigned next index value because it comes after the previous one, and is multi-instance Time 4 x-ID[0]="from template" x-ID[1]="from request" Contact Information[0]="Jim (from request)" -- replaces index 0 because request-defined takes precedence, and single instance Option 2 logic: x-ID from the request gets index 0 because request-defined attributes take precedence over Template-defined attributes. Contact Information from the request is assigned because the standard says that request-defined attributes take precedence over Template-defined attributes. Time line: Time 1 x-ID[0]="from template" Time 2 x-ID[0]="from template" Contact Information[0]="Jim (from template)" Time 3 Contact Information[0]="Jim (from template)" x-ID[0]="from request" -- inserted before previous instance because request-defined takes precedence, and multi-instance x-ID[1]="from template" -- index incremented because request-defined takes precedence, and multi-instance Time 4 x-ID[0]="from request" x-ID[1]="from template" Contact Information[0]="Jim (from request)" -- replaces index 0 because request-defined takes precedence, and single instance Both options are logical, and both can be justified. Both options process attributes in the same order. Both options handle precedence rules for single-instance attributes identically. Both options result in a deterministic assignment of index values that the client can rely on. The only difference is that Option 2 applies precedence rules to multi-instance attributes in a manner consistent with the single-instance precedence rules, whereas Option 1 does not, using instead, order of arrival. In one "KMIP model" (option 1), precedence rules apply to single-instance attributes. In this model the order in which multi-instance values are processed determines the multi-instance index value, regardless of whether the attribute is define in-template or in-request. This model assumes that the server processes attributes in sequential order from first appearing in the request message to last. (I should point out that the standard explicitly addresses the possibility of non-sequential first to last processing when talking about batch processing. Different context to template-defined vs. request-defined attributes, however the (batch processing) "KMIP model" makes no assumption that server operations have to or will be in any particular order.) In the other "KMIP model" (option 2), precedence rules are consistent for single-instance and multi-instance attributes for the purposes of assigning multi-instance index values when attributes are defined in Templates and in requests. Again, I'm not trying to say one option is better or worse than the other. I do strongly believe that both options are valid, and that there is nothing in the standard that precludes option 2 from being conformant. John