OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Get Attributes


This is one of those that seems it would be best handled by profiles as different use cases may require specific return results based on a given use case or a specific attribute type.  As part of a profile that makes use of repeated attributes there should be some form of guidelines for creating profiles that dictates how the profile must be set up for each attribute that can be repeated more than once as some use cases may have two or more repeated attribute fields so that each needs specific guidance (ugly use case potentially but should be possible).

This would allow us to leave it open ended and let the servers and clients that conform with a specific profile to be addressed as needed.

It may sound like we are throwing a lot out to the profiles but I feel that is how it should be so that any system that requires key management could make use of a common service.

Bob L.
________________________________________
From: Tim Hudson [tjh@cryptsoft.com]
Sent: Thursday, May 12, 2011 08:42
To: kmip@lists.oasis-open.org
Subject: [kmip] Get Attributes

When a client requests a list of attributes what should the server behaviour be
when an attribute is repeated more than once?

The specification is currently silent on this topic.

The current set of behaviours for servers that have been implemented are:

        1) return only one result
        2) return copy of the result for each request
        3) reject the request returning OPERATION_FAILED

Which behaviour or behaviours should be permitted within KMIP should be clearly
specified - I think we are in consensus on that.

Which answer is the 'right' one is somewhat less clear.

If the answer is 2) is it allowable for the value results to vary between
attributes - consider a server where the attributes are re-fetched for each item
in the list and the values are changed by another client during the execution.

There are good arguments for each of the alternatives and the Cryptsoft
preference is for option 1)

Separately on the topic Bruce raised - should this be seen as an update to 1.0
or a behaviour change which should be added into the work items for 1.1.

Thanks,
Tim.




---------------------------------------------------------------------
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]