[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: What can you do to the ASN.1 wo getting into trouble with the IESG?



At 10:56 AM 8/30/00 +0200, Leif Johansson wrote:
>I have often wondered about why there are so many apparently equivalent
>versions of AttributeTypeAndValues and derivatives thereof:

I believe it is a notational convenience used to express different
semantics in the specification.  I believe it appropriate to use
notational conveniences when and where it helps produce a clear
and concise specification.

Note that implementors are not required to make direct use of the
provided ASN.1.  They may employ whatever means they desire to
produce a sequence of compatible PDUs.

>without revving the version?

There are varying opinions on how much ASN.1 change may occur,
if any, before the version should be changed.  RFC 2251 provides
one opinion:
   Note that unlike X.500, each change to the LDAP protocol other than
   through the extension mechanisms will have a different version 
   number

If taken literally, the specification has to be taken "as is"
(excepting maybe clarification) to Draft Standard and, eventually,
Standard.  I am more of the opinion that limited changes can be
made without revving the version number.  Basically, I believe we
can fix what is broken as long as we don't break what works.  The
appropriate "fix" may be removal of the broken feature.

In terms of the particular change you suggest, I don't see
the existing ASN.1 as broken and, hence, I see no need
to fix it.

Kurt