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]
