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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Wed, Jul 29, 2009 at 11:21:11PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
>> 
>> > Jeff Hutzelman points out that RFC2744 specifically requires that all
>> > gss_buffer_t outputs be released.  That wouldn't bother me at all here
>> > (we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
>> > RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
>> > chance to do that and didn't, so I'd say that these output buffers
>> > should be released by the app.
>> 
>> Good catch, I have removed the paragraph.  How memory should be managed
>> by applications (i.e., they have to be released) then follows directly
>> from the normative RFC 2744 and GS2 shouldn't say anything about it.
>> Alexey, I hope this resolves your question.
>
> It's useful for GS2 to remind the reader of the application's
> responsibility to release these buffers (RFC5587 will do just that).

RFC 2743 uses comments on the output variables, so I used the same, as
in:

   o sasl_mech_name UTF-8 STRING -- SASL name for this
     mechanism; caller must release with
     GSS_Release_buffer()

   o mech_name UTF-8 STRING -- name of this mechanism, possibly
     localized; caller must release with GSS_Release_buffer()

   o mech_description UTF-8 STRING -- possibly localized
     description of this mechanism; caller must release with
     GSS_Release_buffer()

/Simon