Re: [kitten] Opsdir last call review of draft-ietf-kitten-rfc5653bis-05

Hi Joe

When I said it's a compatible change, I meant the behavior is compatible, so either initSecContext or acceptSecContext still throws an exception instead of returning KRB-ERROR in a byte array. I know "compatibility" has lots of different meanings.

If this method is called directly (not via refection) it will only compile with a new JDK. The program will not run with an old JDK because in Java the class file contains a magic number that increases with each version. This happens before you can see a NoSuchMethodError.

If a developer wants an application or library runnable with an old JDK release but also like to benefit from the new method when running with a new release, some kind of reflection (GSSException.class.getMethod) is needed. In this case the developer will certainly be aware that this method might not exist and deal with it carefully.

I feel hesitated to add reflection calls to all examples since that will look quite a mess. How about changing the last paragraph of Section 11 1) to something like:

   New JGSS programs should make use of this new method but it is not mandatory.
   A program that intends to run with both old and new Java releases can use
   reflection to check the availability of this new method and call it accordingly.

Thanks
Max

> 
> On Sep 6, 2017, at 3:00 AM, Joe Clarke <jclarke@cisco.com> wrote:
> 
> Reviewer: Joe Clarke
> Review result: Ready
> 
> I have been asked to do an LC review of draft-ietf-kitten-rfc5653bis on behalf
> of the ops directorate (OPS-DIR).
> 
> This draft is an update to the Java bindings for the Generic Security Service
> API Version 2.
> 
> Overall, this document is READY.  It clearly articulates the reason for the
> modifications in the Appendix, and the changes feel straight-forward and make
> sense in light of the C API capabilities.
> 
> My one concern is the compatibility of this change relative to the previous
> RFC5653 bindings.  That is, the previous GSSException does not have a
> getOutputToken method.  The sample application in the draft (section 7) calls
> this new method (and I like the same covers the relevant change in this doc). 
> But what happens if my Java library is the older 5653 version?  A
> NoSuchMethodError will be thrown, which is not ideal.
> 
> If there is a set of static properties one can check to see if they have the
> supported version of the library (and thus the GSSException.getOutputToken()
> method exists), then the example should use those, and that process should be
> called out in the text.  In lieu of that, introspection could be used to
> determine if the new method exists in the current library before it is used.
> 
> This is immediately a concern with any API change, but since the appendix
> mentions this is a compatible change, I wanted to raise the point.
> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten