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

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 10:30:08 -0600

On Tue, Nov 07, 2006 at 10:43:25PM +1000, David Leonard wrote:
> Hi,
> 
> Comments regarding draft-ietf-kitten-extended-mech-inquiry-02.txt

These should be sent to the list.

> There is a typo in 3.3 "GSS_C_MA_WRAP wap" ... probably should be "wrap"

Indeed, thanks.

> Table 2's entry for GSS_C_MA_ITOK_FRAMED refers to rfc2743, not [RFC2743]

Will fix.

> In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be 
> returned. I think it should be expected that a future caller could be 
> searching for an attribute OID that the implementation doesn't know about.

GSS_Indicate_mechs_by_attr() could just return an empty OID set instead
of GSS_BAD_MECH_ATTR.  See below.

> s 3.5.3 does not mention language/locale/encoding with the short_desc 
> and long_desc description output of GSS_Display_mech_attr(). Is that 
> deliberate? Could I assume it will sensitive to the 'current' locale, 
> and return UTF-8? I notice RFC2743 doesn't address this with the other 
> GSS_Display calls, so maybe this is addressed more generally?

RFC2743 does not address this, no.  RFC2744 says "Latin-1."

Our conclusio is that outputs from functions such as
GSS_Display_status() are in the codeset of the current locale and in the
language of the current locale.

> Also, in s3.5.3 would it be reasonable to allow the return of empty or 
> null descriptions from GSS_Display_mech_attr()?

I suppose so, or a string that says "description missing" or something
to the effect.  A complete implementation wouldn't, of course.

Note that here GSS_BAD_MECH_ATTR is useful.

Perhaps we should rename GSS_BAD_MECH_ATTR to GSS_UNKNOWN_MECH_ATTR.

Nico
-- 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: David Leonard <[email-masked]>
Date: Wed, 08 Nov 2006 07:54:32 +1000

> of GSS_BAD_MECH_ATTR.  See below.

Yes, I think it should.

> RFC2743 does not address this, no.  RFC2744 says "Latin-1."

Thanks for the RFC2744/Latin-1 pointer.

Also, should the two tables in the draft correspond to the short and 
long descriptions from GSS_Display_mech_attr()? That is to ask was it 
your intent that the short and long text of (say) GSS_C_MA_MECH_CONCRETE 
in English should be "concrete-mech" and "Indicates that a mech is 
neither a pseudo- mechanism nor a composite mechanism" respectively? I 
ask this as implementation guidance, but perhaps the draft might benefit 
by explicitly recommending such an approach? (Otherwise the meanings of 
long and short are floating)

This also leads to the idea of (ab)using GSS_Display_mech_attr() to 
search for an attribute OID by its short description. That strikes me as 
a pretty attractive thing to do when processing human-entered 
configuration files. Sadly, it's precluded because "human-readable" 
doesn't mean "matchable to what a human writes" (but it does make me 
wonder about human-convenient namespace for OIDs.)

> ...

I think keep it BAD, which is consistent with GSS_BAD_MECH and is used 
to mean "unrecognized" amongst other things.

Thanks!

David Leonard

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 16:55:35 -0600

> >of GSS_BAD_MECH_ATTR.  See below.

OK, I think that's reasonable.

> Thanks for the RFC2744/Latin-1 pointer.

Wait for the slides for today's meeting to be posted :)

> long and short are floating)

Implementors would be free to use whatever shodt/long desc they wish,
provided that the semantics they express agree with those described in
the document.  The semantics of these attributes though are fixed or can
be extended only in ways that are backwards compatible if we ever need
to.

> wonder about human-convenient namespace for OIDs.)

Oh yes, the short description is useful precisely for that.  I suppose
that means that the short-desc should not be translated in message
catalogs.

> to mean "unrecognized" amongst other things.

OK.

Thanks,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Nov 2006 18:04:27 -0500

> that means that the short-desc should not be translated in message

This sounds very fragile to me.  If the descriptions are provided by the 
implementation, then they could change if an app is linked against a 
different implementation, or even a different version, and with the magic 
of shared libraries, _that_ could happen without the app even knowing it. 
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.

If we think attributes should have mnemonic names suitable for use in 
config files, there should be an explicit interface for this, rather than 
using GSS_Display_mech_attr() "in reverse", and we should either establish 
a registry for such names, or else explain the perils of using them in the 
absence of such a registry.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2006 17:16:48 -0600

> of shared libraries, _that_ could happen without the app even knowing it. 

Maybe we should get rid of the short description entirely then.  Apps
should know these things by their symbolic names and/or OIDs only and be
done.  See below.

> 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?

> absence of such a registry.

I'm opting for removing them.  Apps could always drop the GSS_C_MA_
prefix to get a mnemonic.  I figure you'll still argue for a function
that can lookup stringified mech attr names (e.g., "CONCRETE"
or "GSS_C_MA_MECH_CONCRETE" as opposed to the symbol
GSS_C_MA_MECH_CONCRETE) and return an OID, and seeing the wisdom of this
I'll add one :)

Thanks,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Nov 2006 19:16:27 -0500

>> 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.
>

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".

>> config files, there should be an explicit interface for this, rather
>> than  using GSS_Display_mech_attr() "in reverse", and we should either
>> establish  a registry for such names, or else explain the perils of
>> using them in the  absence of such a registry.
>

I might make such an argument, after I read the full document.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2006 22:00:49 -0600

> 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.

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.

> I might make such an argument, after I read the full document.

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

GSS_Mech_attr_name_to_oid(string ma_name) {
    static mech_attrs = {};

    if (isempty(mech_attrs) {
	mechs = GSS_Indicate_mechs_by_attr(
		    desired_mech_attrs = GSS_C_NO_OID_SET,
		    except_mech_attrs = {});

	foreach mech in mechs {
	    mech_attrs += GSS_Inquire_attrs_for_mech(mech);
	}
    }

    for mech_attr in mech_attrs {
	(symbolic_name, description) = GSS_Display_mech_attr(mech_attr);

	if (ma_name == symbolic_name || "GSS_C_MA_" + ma_name == symbolic_name)
	    return (mech_attr);
    }

    return (GSS_C_NO_OID);
}

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Nov 2006 14:33:38 -0500

On Monday, November 20, 2006 10:00:49 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> 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".
>

OK.

> 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.

> 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.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2006 15:20:04 -0600

> direction, we should just provide the API for it.  If not, not.

Most apps wouldn't need it, but things like IDEs would, so I would say,
yes, we need such a utility function.

Nico
--