kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: FW: [kmip] KMIP :: Doubts
- From: Mathias Bjoerkqvist1 <MBJ@zurich.ibm.com>
- To: Somanchi Trinath-B22327 <B22327@freescale.com>
- Date: Tue, 5 Oct 2010 10:50:24 +0200
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.
> [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.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]