Max (Weijun) Wang wrote:
On Feb 18, 2009, at 6:17 PM, Xuelei Fan wrote:
> If you find the webrev too long, you might only review a part of it.
sun/security/x509/SubjectInfoAccessExtension.java:
This class looks fine for me except that the SubjectInfoAccessSyntax
is introduced from RFC3280, so I think it would be better change line
50 from RFC5280 to RFC3280.
It was introduced in a previous RFC, but I think if the definition is
not changed in a newer RFC, using the new RFC in the document is not a
bad thing.
This is the process I would choose regarding old and new spec:
If you're writing something new, always try to use the new spec, and
document it. For existing codes, if there's no enhancement in the new
spec, simply update the document link in the codes to point to the new
one. Otherwise, keep the old document link until the codes is updated to
reflect the new features, and then update the document link.
Does this sound rational?
I think we should try to be more consistent. I think it is confusing if some
code/classes reference RFC 2459, others reference 3280 and others 5280 as the
RFC should be treated as a whole. Towards the end of JDK 6 release, I changed
all of the RFC 2459 references to RFC 3280 and made sure we passed all of the
mandatory PKITS [1] tests. For JDK 7, we should be aiming to be compliant with
RFC 5280. I have not done a careful analysis of that document to know if we need
to make any changes or not. I am not sure if the PKITS test suite will be
updated to RFC 5280.
My suggestion for now would be to leave the references as RFC 3280 and open a
separate RFE for JDK 7 to check our APIs and implementation with respect to RFC
5280, fix any issues, and then update the references.
--Sean
[1] http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html
