A major item for the list: ISO evolution control over ASN.1.
(( just think about the MACRO use and fate between 1988 and 1994! ))
My point exactly I think that ASN.1 is a good idea that a committee has
destroyed. The intelectual integrity of the design was lost.
Making people write code to participate in standards debates does have some
usefull properties, it means that some really nasty ideas get dropped and
stops systems from being declared standards to early.
but to keep the balance, as something that deserves attention
when designing the successor, I will mention PER from Simon Spero
Simon did not invent PER, he is using it for NG and is its main apostle.
I don't think he is all that attached to PER per se, he wants to have
something that lets him do that type of thing.
Another point.
I don't know if this will be possible, but I would like the new "decent
something" be such that it would not force the suppliers of the few
decent ASN.1 toolsets to have to throw away there whole architecture
and restart from scratch
Agreed, I'm not sure that we are at that point yet, if we are I must admit
I've cut code about two months ago, basically looking at rationalising an
ASN.1 compiler that grew too many fixes. I'm using it for some projects I
need to work rather than looking to make a proposal though.
I don't think that ASN.1 is a workable solution for many Web applications.
I think it will cause the specifications to become more complex than
they need be. I don't think that X.059, MOSS, etc is an area where the
breaking point would come however. HTTP-NG is more likely to be that point.
With reference to the trilateral commission, it is clear who invented ASN.1
and what their purpose was (stopping PEM), as in OMEN I simply reverse the
name to obtain its meaning.
Phill