RE: [kmip] Mutating Attributes

["Rod Wideman" <Rod.Wideman@quantum.com>]

I think failing the request would make more sense, even in these cases.

 

thanks,

Rod Wideman

Quantum Corporation

(please disregard the confidentiality statement below)

---

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 11, 2009 8:52 AM
To: Frindell,Alan
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Mutating Attributes

Alan, 

The main reasons why a server (according to its 
server-specific policies) might decide to fail a request or instead mutate the 
client-provided attribute value are mainly to prevent: 

- collisions with already assigned names, 
- backdating of the lifecycle dates, 
- use of algorithm parameters considered 
insecure. 

Such situations should be 
rather infrequent. 


Regards, 
-Robert 

"Frindell,Alan" <Alan.Frindell@safenet-inc.com> 
wrote on 06/10/2009 07:53:32 PM:
>
> I think allowing the server to 
choose a value for an attribute other
> than the value sent by the client 
in a request is going to make
> interoperability more challenging. 
 As currently defined, the client
> must be ready for the server to 
override (mutate) any attribute.  There
> may be cases where the 
client application would prefer the request fail
> than have a particular 
attribute mutated.  
> 
> I think by default the server should 
either accept the all of the
> client's requested values, or fail the 
request entirely.  There can be
> specific allowances in the 
specification for attributes where mutation
> is deemed acceptable. 
 I think this eases the interoperability challenge
> for clients by 
limiting the scope of what is allowed to change.
> 
> 
> -Alan 
Frindell
> SafeNet, Inc.
> The information contained in this 
electronic mail transmission 
> may be privileged and confidential, and 
therefore, protected 
> from disclosure. If you have received this 
communication in 
> error, please notify us immediately by replying to 
this 
> message and deleting it from your computer without copying 
> or disclosing it.
> 
> 
> 
> 
> 
---------------------------------------------------------------------
> 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 
>

---

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.