>>>>> "Martin" == Martin Rex <[EMAIL PROTECTED]> writes:
Martin> 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?
Martin> Not for GSS-API _v2_.
Martin> You can add an appendix with guidelines for multithreaded
Martin> environments, but new requirements at this late time (8
Martin> years of installed base) are a pretty bad idea.
Agreed.
Martin> I
Martin> mentioned that before, although the formal standards level
Martin> of GSS-API v2 is proposed, the de-facto level is full
Martin> standard--what's missing is the sorting-out of the
Martin> features that are currently in the standard and that have
Martin> interoperability problems and strong words of caution
Martin> added.
I agree this is the approach that should be taken by anyone wanting to
progress GSSAPI V2.
I'm uncomfortable with the claim that the de facto standardization
level of GSSAPI is full standard. But I don't think it matters
whether I agree with that claim at all. I certainly agree that there
are a lot of GSSAPI V2 applications and mechanisms out there working
today. I agree that breaking these applications or mechanisms would
have a very high cost. I also agree that the API and protocols
described by the GSSAPI V2 documents do work for a large number of
applications. If that's what you mean by de facto standardization
level of full standard, then I agree with what you are saying although
perhaps not the words you are using.
I'm also uncomfortable with the idea that we cannot change GSSAPI V2
in a backward incompatible way. I cannot think of a reason at the
current time why it would be a good engineering decision to change
GSSAPI V2 in a backward incompatible way. But I believe the statement
that we cannot do so is false.
The reason we should not change GSSAPI V2 in a backward incompatible
way is that doing so has very high cost. It would presumably break
some or all applications and mechanisms. ALso, by not changing the
version number we'd create significant confusion. But the cost to
changing GSSAPI in an incompatible way is not infinite; it is only
very high.
Let's say we found a serious security or interoperability problem in
GSSAPI V2. It would be reasonable for us to evaluate the tradeoffs
involved in making a backward incompatible change and there might
exist situations where the costs are justified.
Nothing I've brought up on the list in the past weeks falls into the
category of things that would justify a backward incompatible change.
My personal preference is to work on what I expect to be a GSSAPI V3
rather than work on advancing the current documents. I don't mind
seeing the protocol and API described by GSSAPI V2 be advanced, I just
don't expect to have time to work on both that task and the extensions
I expect to need for other IETF work.
--Sam
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]
