Hi Emmanuel, I understand your review comments and actually they're very insightful. I may be a little nervous but I did have to convey the current situation the codes in so that you can aware it why I would insist on some points for myself. Some of the codes are still initial and lacking something, that does not mean we shouldn't the project. As you may understand, a project may be released out with some features still in its experimental status unless the feature itself isn't claimed to be available. Kerberos contains quite a few extensions and updates since 4210, as you may be noted, we're incrementally implementing them one by one, and some of them may come across some RCs or even formal releases. So all in all, please don't be surprised when you see still immature codes when you're doing the great review. Thanks.
While you're reviewing, I would try to address your questions in timely manner because not only we should, but also I think it's important for the project's long term, though it's not so exciting as writing something new. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Monday, January 04, 2016 5:51 PM To: [email protected] Subject: Re: AP-REP message Le 04/01/16 08:39, Zheng, Kai a écrit : > I know and agree with the point you made here. What I would say is that, our > Kerberos implementation codes are still lacking many things and to be evolved > fast. We may see many classes, variables, methods and codes are not > referenced in the existing codes, it's normal because we have so much to fill > yet. Given you have reviewed quite a few of the codes, I guess you might > understand that why we define and write those classes or methods not used > yet, because in many times we follow a RFC spec, or a fixed pattern and make > up many of them, either for completeness, for the future we'll use them at > all, or just for our customers they need the library to do something. I'm fine with that. It's just that as there is no documentation in the code, it's hard to know where it's coming from, and what it might be good for in the near future. A simple Javadoc saying 'not used atm, will be in the near future', or 'part of a RFC draft http://blah' would help. > > Decrypted result in Kerberos is surely to be passed elsewhere and handled in > various procedures or components, considering it often contains many > information. We just can't do all the logics in a single place because that > would result in a very large function or class. I guess the codes you noted > are still very initial for now, which means we have many things to fill in > the places. Sorry I haven't checked the codes you mentioned, but I would if > our Kerby codes are going to be close to the final status with all the > available functionalities existing in MIT Kerberos already fine implemented. We are talking about releasing RC2, and we already have released a RC1 (Release Candidate) ;-) So maybe it's premature to call it a Release Candidate, and we should name them Milestone ? > Obviously, we're not. Sadly, we won't in a fair term future. Otherwise it's > unfair, Kerberos has evolved past more than twenty years, we just can't catch > up with the mainstream simply in one or two years. The simple fact that our Kerberos Implementation at ApacheDS haven't reach a full coverage of the Kerberos specifications in 10 years is just making your point ;-) Sorry if my mails make you think I find it wrong, I'm just trying to point fingers on parts that, in my opinion, might need some improvements. If I'm lucky, I find bugs, or areas where more work need to be done, and that's the purpose of this review. It's also for me a way to get involved in this code... Thanks Kai ! I'll keep the methods at the moment.
