GSS IOV flags
Luke Howard
lukeh at padl.com
Wed Dec 17 06:17:06 EST 2008
Hi Metze,
> #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.
Can you think of any reason where we might need something that behaves
like SECBUFFER_EMPTY?
>> #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?
I tried to keep the types aligned with the equivalent SSPI types, to
make it easier for anyone that might want to build a shim (in either
direction).
>> #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'
OK, will fix.
-- Luke
More information about the krbdev
mailing list