[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] s2s inspired changes to KMIPv1
All, please find below a formal proposal for the s2s inspired changes to KMIPv1, as discussed on the previous calls. Regards, Marko --------------- 1) Proposed changes to Put Add after sentence ending in line 1465: "In case the object with the Replaced Unique Identifier does not exist at the client, the client SHALL interpret this as if the Put Function contained the value New." 2) Proposed changes to Notify i) In the Description column of the Attribute Object in Table 164, add the following as the last sentence. In case an attribute was deleted, the Attribute structure (see 2.1.1) in question SHALL NOT contain the Attribute Value field. and ii) in Table 1, row Attribute Value, column "REQUIRED": "Yes" should be replaced with "Yes, except for the Notify operation (see Section 5.1.) 3a) Proposed change to Locate The sentence in lines 1147-1149 should be replaced with the following: "Wild-cards or regular expressions (defined, e.g., in [ISO/IEC 9945-2]) MAY be supported by specific key management system implementations for matching attribute fields when the field type is a Text String or a Byte String." 3b) Proposed change to Locate i) The following sentence replaces the first sentence of the text of Locate: "This operation requests that the server search for one or more Managed Objects depending on the attributes specified in the request." and ii) the following sentence should be added to the text after the sentence ending in line 1138: "If no attribute is specified in the request, any object SHALL be deemed to match the Locate request. and iii) in table 127, row "Attribute", column "REQUIRED", the text should be changed to: "No, MAY be repeated" -------------------- From: Marko Vukolic2 <MVU@zurich.ibm.com> To: kmip@lists.oasis-open.org Date: 01/14/2010 01:55 PM Subject: [kmip] s2s inspired changes to KMIPv1 During the work on server-to-server extensions of KMIPv1, we came up with few proposals for spec changes that the TC might consider for inclusion already in the KMIPv1. The benefit of this would be reducing the differences between KMIPv1 and its future versions. These could be accepted as a part of public review. We believe that the changes proposed below are not strictly related to server-to-server (although the need for them appeared in this context). Furthermore, most of the changes seem pretty lightweight and acceptable. The proposed changes are included below. Best regards, Marko Vukolic ---------------- Issue 1: The behavior of Put when Replaced Unique Identifier (ruuid) is specified, but the object with ruuid does not exist on the remote end (client) is not specified. Specifying this behavior might enhance interoperability. Proposed resolution: The client (remote end) ignores the ruuid and acts like it was not specified. Issue 2: Notify does not support notification about deleted attributes. Proposed resolution: Augment Notify to support attribute deletion notification (to be detailed). Issue 3: the optional support of wildcards in Locate is stated only for Name and Object group. It is not clear why other attributes that are represented as Strings are not supported by the wildcards. This seems to be a leftover from the early days of KMIP in which Locate supported only a subset of attributes. (lines 1147-1149) "1147 When using the Name or Object Group attributes for identification, wild-cards or regular expressions 1148 (defined, e.g., in [ISO/IEC 9945-2]) MAY be supported by specific key management system 1149 implementations" Proposed resolution: replace in line 1147 "Name or Object Group" with "Unique Identifier, Name, Certificate Identifier, Certificate Subject, Certificate Issuer, Digest, Operation Policy Name, Revocation Reason, Object Group, Link, Application Specific Information or Contact Information". Issue 4: Not possible to "Locate All" objects in KMIPv1. This functionality is very useful in the server-to-server context but might be nice to have even for client/server. Proposed resolution: Omitting all attributes from a Locate request could be interpreted as "Locate All" ------------------- --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]