Re: WG Last Call: draft-ietf-sasl-gs2-14

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>> Alexey Melnikov <alexey.melnikov@xxxxxxxxx> writes:
>> > 6).
>> >
>> >> 10.1.  gss_inquire_saslname_for_mech
>> >>
>> >>    The C binding for the GSS_Inquire_SASLname_for_mech call is as
>> >>    follows.
>> >>
>> >>       OM_uint32 gss_inquire_saslname_for_mech(
>> >>         OM_uint32     *minor_status,
>> >>         const gss_OID  desired_mech,
>> >>         gss_buffer_t   sasl_mech_name,
>> >>         gss_buffer_t   mech_name,
>> >>         gss_buffer_t   mech_description,
>> >
>> > Do the 3 output parameters need to be freed?
>> 
>> Not sure if this needs to be mentioned, I can't find much discussion in
>> RFC 2743 on this.  Nico?
>
> Things that are constant-like don't need to be freed.  For example,
> mechanism OIDs returned by GSS_Indicate_mechs(),
> GSS_Inquire_sec_context(), ...
>
> The same should apply here to these three output arguments.
>
> Yes, that means that if an implementation were to malloc memory for
> them, then it could only freed them when the shared object is unloaded
> or the process exits.

The GS2 document could also say that applications needs to release
memory for these output variables.  However, I think these three output
variables would typically be stored in static storage and wouldn't need
to be released.  We could clarify this.  How about adding

   The memory allocate for the output variables need not be released
   by the application.

to the sections for new GSS-API interfaces?

/Simon