Hi-
Please help me understand these doubts..
From: Somanchi
Trinath-B22327
Sent: Thursday, September 30, 2010 12:57 PM
To: 'Robert Haas'
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] KMIP :: Doubts
Hi-
I have the following more doubts:
[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.
[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
[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?
Please help me understand these doubts.
Trinath Somanchi,
trinath.somanchi@freescale.com
Hi Trinath,
please see below.
Regards,
-Robert
Somanchi Trinath-B22327
<B22327@freescale.com> wrote on 09/29/2010 06:39:50 PM:
>
> RE: [kmip] KMIP :: Doubts
>
> Somanchi Trinath-B22327
>
> to:
>
> Robert Haas
>
> 09/29/2010 06:43 PM
>
> Cc:
>
> kmip
>
> Some issue with my mail client, So resending this mail again, Ignore
> if already received this email
>
> Thank you
>
>
> Hi Robert,
>
> Thank you for the reply.
>
> My 3rd doubt is still not cleared. Use case 3.1.3 from the use case
> document uses UUID in locate request. I think I was not clear in
> expressing my doubt.
>
> Here is my Doubt:
>
> In Use case 3.1.3, Locate request, UUID is given in the request
> payload in an Attribute Structure as:
>
> Tag: Attribute (0x420008), Type: Structure (0x01), Data:
> Tag: Attribute Name (0x42000A), Type: Text
String (0x07),
> Data: Unique Identifier
> Tag: Attribute Value (0x42000B), Type:
Text String (0x07),
> Data: 1ed28ea5-2b31-4145-bcf2-36d0756d3890
>
> But in GET operation request, UUID is given in Unique identifier Tag.
Like,
>
> Tag: Unique Identifier (0x420094), Type: Text String (0x07), Data:
> 1ed28ea5-2b31-4145-bcf2-36d0756d3890
>
> My doubt is that, why two types exists for UUID specification?
Thanks for helping me understand your
question better.
Parameters to operations can be base objects
(defined in section 2), parameters that correspond to attributes (defined in
section 3), enumerations (defined in sections 9.1.3.2.*), or objects that are
defined in the operation itself.
In addition to these parameters that must be
listed explicitly in each operation request or response specification, a small
set of operations allow to pass parameters that are NOT explicitly listed one
by one. This is the case for Locate, Notify, Put, Get Attributes,
Add/Modify/Delete Attribute. This is done with an attribute structure with name/index/value,
that allows to pass multiple instances if needed.
In the example you raised, Unique Identifier
is not treated differently than other such attribute parameters passed to
Locate for matching purposes.
>
> I mean why can't UUID specified in Attribute structure (present in
> locate) be used in GET operation request also?
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.
>
> Is there any specific reason behind the framing of request in this
way?
>
> Please help me understand this.
>
>
> Best Regards,
> --------------------
> Trinath Somanchi.
> email : trinath.somanchi@gmail.com
> Mobile: +91 9866 235 130
>
>
>
>