Hi Mathias,
Thank you for the reply..
Please see below for my responses ..
Trinath Somanchi,
trinath.somanchi@freescale.com
From: Mathias
Bjoerkqvist1 [mailto:MBJ@zurich.ibm.com]
Sent: Tuesday, October 05, 2010 2:20 PM
To: Somanchi Trinath-B22327
Cc: kmip@lists.oasis-open.org
Subject: Re: FW: [kmip] KMIP :: Doubts
Hello Trinath,
Please see below for my responses to your
questions.
Regards,
Mathias
Somanchi Trinath-B22327
<B22327@freescale.com> wrote on 05.10.2010 06:12:52:
>
> [1] With respect to your comment
“It's a decision in the
> specification to use the straight TTLV encoding for parameters that
> are explicitly specified (whether they are attributes, base objects,
> or enumerations), as opposed to using the heavier attribute name/
> index/value structure used only in the cases I mention above. “
Why
> can’t Locate operation request have light structure like in Get
> operation? Why Get operation itself should have light weight
structures.
>
If we had the same light structure in Locate
as in Get, we would have to
use different representation for Custom
attributes and other attributes
(since normal attributes could be identified
by a tag, whereas Custom
attributes can only be identified by the
text string name). We felt it
was a better design to treat all attributes
in the same way, rather than
going for smaller message size by treating
custom attributes differently.
In Get it makes sense to have the light
structure, since only a specific
subset of parameters can be passed in the
request.
[B22327] But then in GET operation If I want to get a key using
some custom attribute which the user thinks is the unique one. How we go about
it?
> [2] In the Use case document, in the
starting sections a Template
> was created and using the same a symmetric key is generated. But
> while using the template in Symmetric key creation, NAME of the
> Template is mentions in Simple NAME structure. Can UUID be also be
> used in place of NAME to identify the template to be used while
> creating the symmetric key.
>
> Now the template is identified by its
NAME this way,
>
> From Use case Doc, section 3.1.2
> Tag: Template-Attribute (0x420091),
Type: Structure (0x01), Data:
> Tag: Name
(0x420053), Type: Structure (0x01), Data:
> Tag:
Name Value (0x420055), Type: Text String (0x07),
> Data: Template1
> Tag:
Name Type (0x420054), Type: Enumeration (0x05), Data:
> 0x00000001 (Uninterpreted text string)
>
> So when giving UUID of the Template
object, can UUID be given this way,
>
> Tag: Template-Attribute (0x420091),
Type: Structure (0x01), Data:
> Tag: Unique Identifier (0x420094),
Type: Text String (0x07), Data:
> fc8833de-70d2-4ece-b063-fede3a3c59fe
>
When referring to Templates in Register,
Create, Create Key-pair etc.,
it is only possible to identify the Template
by name, not by UUID.
This was a conscious design decision. This
is because we wanted the
Template reference to be human-interpretable
and rememberable.
[B22327] okay.. then is it okay to send UUID if needed or MUST
follow this way
Please see Section 3.6 in the Usage Guide
for more information on
how to use Templates.
> [3] What is the use of Criticality
Indicator? In the Use case
> document I see two use cases for showcasing this attribute.
> In the first use case, it is set to
false, symmetric key is created,
> since the server did not understand the extension, and criticality
> indicator is set to false, the server created the symmetric key.
> In the second use case, criticality
indicator is set to true, server
> did not understand the extension and identified criticality
> indicator is set to true, and returned error, symmetric key is not
created.
> Sine in both the cases the new
extension is not understood by the
> server. How this criticality indicator is used?
>
The criticality indicator is defined in
Section 6.16 of the KMIP
specification. It indicates the criticality
of the vendor-specific batch
item extension. If it is only "nice-to-know"
information, then the
client can set the criticality indicator to
false, thus allowing
a server that does not understand the batch
item extension to ignore it
and process the rest of the batch item
normally. If, however, the batch
item extension contains critical information
that substantially changes
the meaning of the request or the normal
parameters passed in the request
payload, then the client sets the
criticality indicator to true. In this
case, if the server does not understand the
batch item extension, it has
to fail the request.
[B22327] Any way in both the cases server doesn’t
understand the extension parameters right? Then what help does this provide. Is
the attribute used to stop throwing an error when such data is sent though
valid at user end.