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@xxxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/kitten