Wherever these GSSAPI C-bindings describe structured data, only
   fields that must be provided by all GSSAPI implementation are
   documented.  Individual implementations may provide additional
   fields, either for internal use within GSSAPI routines, or for use by
   non-portable applications.

2.1.2. Integer types

   GSSAPI defines the following integer data type:

                 OM_uint32      32-bit unsigned integer

   Where guaranteed minimum bit-count is important, this portable data
   type is used by the GSSAPI routine definitions. Individual GSSAPI
   implementations will include appropriate typedef definitions to map
   this type onto a built-in data type.

2.1.3. String and similar data

   Many of the GSSAPI routines take arguments and return values that
   describe contiguous multiple-byte data.  All such data is passed
   between the GSSAPI and the caller using the gss_buffer_t data type.




 
RFC 1509            GSSAPI - Overview and C bindings      September 1993


   This data type is a pointer to a buffer descriptor, which consists of
   a length field that contains the total number of bytes in the datum,
   and a value field which contains a pointer to the actual datum:

                 typedef struct gss_buffer_desc_struct {
                    size_t  length;
                    void    *value;
                 } gss_buffer_desc, *gss_buffer_t;

   Storage for data passed to the application by a GSSAPI routine using
   the gss_buffer_t conventions is allocated by the GSSAPI routine.  The
   application may free this storage by invoking the gss_release_buffer
   routine.  Allocation of the gss_buffer_desc object is always the
   responsibility of the application;  Unused gss_buffer_desc objects
   may be initialized to the value GSS_C_EMPTY_BUFFER.

2.1.3.1. Opaque data types

   Certain multiple-word data items are considered opaque data types at
   the GSSAPI, because their internal structure has no significance
   either to the GSSAPI or to the caller.  Examples of such opaque data
   types are the input_token parameter to gss_init_sec_context (which is
   opaque to the caller), and the input_message parameter to gss_seal
   (which is opaque to the GSSAPI).  Opaque data is passed between the
   GSSAPI and the application using the gss_buffer_t datatype.

2.1.3.2. Character strings

   Certain multiple-word data items may be regarded as simple ISO
   Latin-1 character strings.  An example of this is the
   input_name_buffer parameter to gss_import_name.  Some GSSAPI routines
   also return character strings.  Character strings are passed between
   the application and the GSSAPI using the gss_buffer_t datatype,
   defined earlier.

2.1.4. Object Identifiers

   Certain GSSAPI procedures take parameters of the type gss_OID, or
   Object identifier.  This is a type containing ISO-defined tree-
   structured values, and is used by the GSSAPI caller to select an
   underlying security mechanism.  A value of type gss_OID has the
   following structure:

                 typedef struct gss_OID_desc_struct {
                    OM_uint32 length;
                    void      *elements;
                 } gss_OID_desc, *gss_OID;





 
RFC 1509            GSSAPI - Overview and C bindings      September 1993


   The elements field of this structure points to the first byte of an
   octet string containing the ASN.1 BER encoding of the value of the
   gss_OID.  The length field contains the number of bytes in this
   value.  For example, the  gss_OID value corresponding to {iso(1)
   identified- oganization(3) icd-ecma(12) member-company(2) dec(1011)
   cryptoAlgorithms(7) SPX(5)} meaning SPX (Digital's X.509
   authentication mechanism) has a length field of 7 and an elements
   field pointing to seven octets containing the following octal values:
   53,14,2,207,163,7,5. GSSAPI implementations should provide constant
   gss_OID values to allow callers to request any supported mechanism,
   although applications are encouraged on portability grounds to accept
   the default mechanism.   gss_OID values should also be provided to
   allow applications to specify particular name types (see section
   2.1.10).  Applications should treat gss_OID_desc values returned by