Re: draft-ietf-kitten-extended-mech-inquiry-02.txt

On Monday, November 20, 2006 10:00:49 PM -0600 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

> On Mon, Nov 20, 2006 at 07:16:27PM -0500, Jeffrey Hutzelman wrote:
>> >> This could be solved by defining the short descriptions to be part of
>> >> the  ABI, but then you can't add descriptions for new attribute OID's
>> >> without  making what is essentially a backward-incompatible change.
>> >
>> > I don't see how adding new attributes breaks ABIs.  Can you elaborate?
>> > Or did I misread?
>>
>> Adding _descriptions_ for new attributes breaks the ABI, because a
>> quality  implementation will produce useful descriptions for unknown
>> attributes,  like "unknown-attribute-1.3.6.1.4.1.22484.42.4.1", and that
>> string will no  longer work when the attribute becomes supported and the
>> description  changes to "gco-example-attr-1".
>
> The function in question (GSS_Display_mech_attr()) returns an ERROR
> (GSS_S_BAD_MECH_ATTR) for unknown mech attr OIDs, so nothing like
> "unknown-attribute-1.3.6.1.4.1.22484.42.4.1" will ever be outut by it.

OK.

> And you can't argue that adding new mechanism attributes would break the
> ABI, not any more than you would argue that adding new mechanisms would.

Yes, I agree that adding new values for which it does not return an error 
is not a backward-incompatible change.

> Note that one could implement such a thing in terms of
> GSS_Display_mech_attr().  In pseudo-C-code:

UGH.  If we think people should have any business doing the mapping in that 
direction, we should just provide the API for it.  If not, not.

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten