GSS IOV flags

[Stefan (metze) Metzmacher]

Hi Luke,

> typedef struct gss_iov_buffer_desc_struct {
>     OM_uint32 type;
>     gss_buffer_desc buffer;
> } gss_iov_buffer_desc, *gss_iov_buffer_t;
> 
> #define GSS_IOV_BUFFER_TYPE_EMPTY           0

I think we should define this one a bit more, because
SSPI has this:

#define SECBUFFER_EMPTY 0   // Undefined, replaced by provider
see http://msdn.microsoft.com/en-us/library/aa380533(VS.85).aspx
and http://technet.microsoft.com/en-us/library/bb742535.aspx

I would like to have have a TYPE that's ignore by the provider
completely and the caller can be sure the provider doesn't mofify
it. That's why I originally used:

#define GSS_IOV_BUFFER_TYPE_IGNORE 0

I'm fine with keeping GSS_IOV_BUFFER_TYPE_EMPTY but we should defin
what it means.

> #define GSS_IOV_BUFFER_TYPE_DATA            1   /* Packet data */
> #define GSS_IOV_BUFFER_TYPE_HEADER          2   /* Mechanism header */
> #define GSS_IOV_BUFFER_TYPE_MECH_PARAMS     3   /* Mechanism specific
> parameters */
> #define GSS_IOV_BUFFER_TYPE_TRAILER         7   /* Mechanism trailer */
> #define GSS_IOV_BUFFER_TYPE_PADDING         9   /* Padding */
> #define GSS_IOV_BUFFER_TYPE_STREAM          10  /* Complete wrap token */
> #define GSS_IOV_BUFFER_TYPE_SIGN_ONLY       11  /* Sign only packet data */

any reason for not counting from 0-7?

> #define GSS_IOV_BUFFER_FLAG_MASK            0xFFFF0000
> #define GSS_IOV_BUFFER_FLAG_ALLOCATE        0x00010000  /* indicates GSS
> can allocate */

I think that should be 'indicates GSS should/must allocate'

> #define GSS_IOV_BUFFER_FLAG_ALLOCATED       0x00020000  /* indicates
> caller should free */
> 
> #define GSS_IOV_BUFFER_TYPE(_type)          ((_type) &
> ~(GSS_IOV_BUFFER_FLAG_MASK))
> #define GSS_IOV_BUFFER_FLAGS(_type)         ((_type) &
> GSS_IOV_BUFFER_FLAG_MASK)

In general it looks good.

metze

> On 17/12/2008, at 3:59 AM, Tom Yu wrote:
> 
>> Love expressed a desire to combine the flag and type fields of
>> gss_iov_buffer_desc_struct, but said he was willing to live without
>> it.  Looking at SSPI, the flag and type fields are combined.  Does
>> this change anybody's mind in favor of Love's proposed change?
>>
>> If there is an existing API out there (SSPI), and we can make our
>> implementation look more like SSPI without causing problems for us, I
>> think we should.  Does anyone believe that making this change to align
>> more closely with SSPI will cause problems?
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
> 
> -- 
> www.padl.com | www.fghr.net
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20081217/c10a887a/attachment.bin