Which version of GSSAPI are we talking about

I've perhaps been a bit confusing about whether I'm talking about work
on a GSSAPI V3 or on the V2 specifications.

The short answer is that I don't know, but we should do something
intelligent.

If we end up with a document that adds extensions and doesn't remove
any APIs, I could see calling it GSSAPI V2.  I could also see
requiring that it be called V3 if the implementation needed to supply
new APIs.


If we remove APIs or change the functionality of APIs or make
mandatory features optional, I would not expect the result to be
called GSSAPI V2.  I'm not sure the process strictly speaking requires
us to increment the version number, but I would expect the IESG to
have serious questions if we request publication of a document that
purports to be GSSAPI V2 but is not compatible with existing GSSAPI
V2.  I cannot currently think of a situation where publishing such a
document would be the right thing to do.


I do expect that GSSAPI will need to recycle at proposed (possibly as
GSSAPI V3) before it advances.




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