Dave,
I have some comments regarding statements made in your message:
1) You stated: "specific issue of RIs containing V2 ACs". None of the
RFC2630 RecipientInfo CHOICE types are capable of containing ACs.
2) You stated: "The version number contained within an Attribute Certificate
is sufficient in principle for a decoder of an outer object (EnvelopedData)
to determine whether the inner (AC) version is supported,..." I disagree
with your use of the terms "outer object" and "inner object". The AC syntax
is an integral part of the SignedData and EnvelopedData syntaxes which are
the "outer objects". Changing the AC syntax changes the SignedData and
EnvelopedData (a.k.a. "outer") syntaxes. I still believe that incrementing
the version number when v2 ACs are used is the technically correct position
and is consistent with the use of version numbers in other specs. For
example, when the X.509 certificate and AC syntaxes changed, new version
numbers were defined. I retracted my comment because it seemed that nobody
has operationally used 1997 ACs in SignedData and EnvelopedData objects. If
that is the case, then implementers can design their code to handle only the
new 2000 AC syntax (because the 1997 AC syntax was never used).
3) You stated: "I don't buy the argument that some tools don't do the right
thing and that a
data standard should therefore do the wrong thing (increment
EnvelopedData)." I don't believe that anybody made this argument. I know
that I did not.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================