The message I received from your mails was, however, that
VISA/Microsoft STT design team should adopt ASN.1 and/or one of the
OSI encoding mechanisms. Is this true statement of your position on
STT spec?
My position on the STT specification is that it is not ready for
primetime in its current form.
Compared to the Cambridge Prefix Notation and the encoding rules that
STT employs (as described in the STT specification), ASN.1 and any of
its sets of encoding rules is better. However, in sending my comments
on STT it did not cross my mind that VISA/Microsoft would alter STT to
use ASN.1. My impression was that STT is not subject to debate, so
only modifications to correct defects would be considered.
I disagree on the ASN.1 vs Cambridge Prefix question but for rather
different reasons.
First ASN.1 is undoubtedly a very good idea. Its a pity that the
implementation of it is very seriously flawed, not to say broken. ASN.1
is a tedious system at best, its unnecessary complexity has resulted in
very large and expensive compilers being needed, none of which work
in my experience. ISODE is merely a bad joke. If programs were meant to
use ISODE God would have given us gigabit RAMs,
The separation of the abstract from the concrete syntax is undoubtedly
the right approach, unfortunately the MACRO, IMPLICiT and ANY features
are a sign of a confused specification which heads off into the concrete
implementation areas it is meant to avoid. IMPLICIT is particularly
bad since it has no sematic implication, only an encoding implication.
On the other hand if embroiled in a standards battle grabbing ASN.1
is definitely a good move, it is more likely to win than another random
bit bagging scheme. Especially if the arena is ANSI or ISO. Apart from
that I don't see that there is a great deal to argue one way or another.
The IETF process is used to specs which appear with the odd problem
when first proposed. That is pretty well inevitable. We have all been
asking for STT to be published ASAP, if there is the odd typo in the spec
we should not be suprised.
The median approach appears to be to use ASN.1 but to use as little of
it as possible, sticking to those features which are well defined and
easy to implement. Do not attempt to obtain compact encodings with ASN.1,
certainly not through manipulating the "abstract" syntax as some
advocate.
Phill