Re: KITTEN BOF at IETF 60?

Nicolas Williams wrote:
> 
> > If it's implementation-specific, then as far as writers of portable 
> > applications are concerned, it might as well be "no".
> 
> Agreed.  The question in mind is: can we just add mt requirements to the
> C-bindings?

Not for GSS-API _v2_.   

You can add an appendix with guidelines for multithreaded environments,
but new requirements at this late time (8 years of installed base)
are a pretty bad idea.  I mentioned that before, although the formal
standards level of GSS-API v2 is proposed, the de-facto level is
full standard--what's missing is the sorting-out of the features
that are currently in the standard and that have interoperability
problems and strong words of caution added.

i.e. what is missing is to figure out which fraction of the current
GSS-API v2 spec is the mature core of a draft standard GSS-API v2.

You did notice that the Appendix on binary-level interoperability
is just a guideline, no requirements there.  


> 
> And doesn't the foregoing apply to the base spec also?

I'm not sure, but I doubt the base spec of GSS-API **v2** should deal
with multi-threading issues.  I don't have any real experience with other
language environments.  Java is said to support multi-threading.
How about concurrent use of gss_ctx_id_t and gss_cred_id_t and
gss_name_t from several threads?  How are such things usually
done in Java?  Are the Mutex-Primitives and are they used to
serialize access to shared objects?

I'm nowhere near a multi-threading guru.  I never liked the concept
and I still think it belongs more to the category of problems rather
than to the category of solutions.  But during the last 4 years
I had to write and support an SSL abstraction for our application
using an OEM library for *ALL* of our platforms.  We do have
source for that OEM library and I've been doing development,
porting and debugging/maintaining that library as well.


> > (Granted, we're talking about recommendations for better compatibility, 
> > not an actual ABI specification.  So if it can't actually work on all 
> > systems, it's not a fatal flaw.)
> 
> One thing I notice now is that the language of rfc2744 seems to make a
> distinction between recommendations for implementations and
> recommendations for platforms.  It seems that a single ABI for any given
> platform is desired.
> 
> I appreciate this but, how is an ABI to be specified for any given
> platform?  No mechanism is provided or discussed for reaching agreement
> on a given ABI for a given platform, so how could competing implementors
> agree?

Experience shows that it is possible to create interoperable implmentations
without a formal ABI, however it often means that one side has to
adapt to the other before it is finalized and shipped--or one may need
glue-code between application and gssapi mechanism to convert
between incompatible binary interfaces.  We have provisions for
loading the glue library in our application and ship a C-source
skeleton for the function wrapper glue code.

I noticed an interoperability problem in the HP-UX 11.i 64-bit Kerberos
library with our code.  I was able to make it interoperate with a
shared library adapter.


> 
> The base spec needs to look after its namespaces.  Each bindings spec
> need to do the same, and if they borrow names from the base spec then
> they need to specify how that affects the language's namespace.

I actually prefer when a spec doesn't create the impression to be
perfect or complete.  When it's obvious that there's something missing,
new implementors tend to take a look at other existing implementations
that are potential candidates for interoperability and copy whatever
that implementation does.  I think that approach works, and it often
works much better as the "we know everything, we spec everything"
approach.

Just look at X.509 and PKIs.  It's an awfully large and complex set
of specs.  Don't expect any two independent implementations to fully
interoperate on their first encounter in the wild.  Have you ever
read Peter Gutmann's X.509 style guide?
(http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt)

I think that a lengthy spec can create more misunderstandings than a short
spec has deficiencies.  With a long spec people are going to fight about
how parts of the spec are meant.  If the spec is silent in some
controversial or not well-researched areas then implementors need to
negotiate and apply common sense if they want to interoperate.

Spec writers may be better off not specifying details which they do
not fully and thoroughly understand themselves.  A detailed spec
can not substitute interoperability testing and resulting adjustments to
the implementations, although many people seem to believe it might.


> 
> > >>  Can I use gss_uint32 in my code?  (True, there's no guarantee that
> > >>  it's the same as OM_uint32.)
> > >
> > >There should be.  It's implicit in the name.
> > 
> > No, what's implicit in the name is that both should be unsigned 
> > integral types of at least 32 bits.  On an ILP32 system, one could be 
> > unsigned int and the other unsigned long.  Mostly compatible in C, but 
> > could trigger diagnostics if you use pointers or multiple declarations. 
> 
> Gross.  Also, I just noticed that rfc2744 section 3.1 says that
> OM_uint32 is at least 32 bits, not exactly.
> 
> And appendix A guarantees gss_uint32 == OM_uint32 if xom.h was missing.

Probably xom.h is missing because the OS vendor made it part of an optional
software package of the operating system and *NOT* part of the compiler.
That is probably the real killer.

Our HP-UX 10.20 build machine has /usr/include/xom.h installed
(where it is part of DCE).  But none of our HP-UX 11.0 and 11.11 build
machine has it installed...  None of our AIX 4.2.1, 4.3.2, 4.3.3 and 5.1
build machines has it and neither has any single one of our Tru64,
Solaris and Linux build machines...

The reference to xom.h is pretty useless today because all the
(Unix) OS vendors apparently unanimously decided that this standard
isn't worth to exist.

The reason why there is a reference to xom.h and X/Open at all is
because there is an X/Open standard for GSS-API and it was published
somewhere between IETF GSS-API v1 (rfc1508/9-1993) and
IETF GSS-API v2 (rfc-2743/4-2000).

However, the DCE-hype has long faded away, except maybe for some niches.


> 
> >  But if the code that interacts with the GSS-API C bindings is written 
> > with the assumption that they could be different types, then it should 
> > be safe.
> > 
> > But the other part of my point was, since the gssapi.h provided is 
> > apparently what is required to be supplied to application writers, then 
> > gss_uint32 must be available, even though it's not directly used in the 
> > API (and if xom.h is available, isn't indirectly used either), or even 
> > mentioned anywhere outside the appendix.
> 
> I think the right answer is: "gss_uint32" is private to gssapi.h (even
> if visible) and should not be used outside it.


Well, maybe we should switch to gss_uint32 instead of OM_uint32 and
remove the references to xom.h and X/Open?


-Martin

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]