Phill,
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.
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.
You no doubt are right, for MACRO and ANY have been removed from
ASN.1; I don't think they would have been removed had they not been
flawed. You will not find any reference to them in the ASN.1:1994
document, except in an annex as a historical relic. The replacement
notations in ASN.1:1994 are *much* tighter syntactically and semantically.
As far as IMPLICIT is concerned you are right again, for in ASN.1:1994
tags are not required at all, though IMPLICIT and EXPLICIT are
retained for backward compatibility purposes. That is, new ASN.1
specifications have no need to ever specify any tags, for as you point
out "it has no semantic implication, only an encoding implication";
you can instead specify "AUTOMATIC TAGS" at the beginning of the ASN.1
module between "DEFINITIONS" and "::= BEGIN". An algorithm described
in ASN.1:1994 is then used to determine the tags if the encoding rules
require tags.
It is only through after ASN.1 was in use that it became clear that
such changes were necessary. Hind sight is 20-20.
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.
Odd typo's do not bother me, severe problems do. Look again at items
1, 2 and 5 of the section "Severe problems" of my mail "comments on
STT"; these are by no means "odd typo's", they are serious
interoperability problems that need to be resolved, as best as I can tell.
Please don't get hung up with my pointing out problems with STT, for
it is new and bugs are a fact of life. The purpose of my mail was to
indicate that STT is not as sound as I had thought, and is in need of work.
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.
Sounds good.
Which features do you consider ill-defined or hard to implement, other
than macros which have been removed? I can think of a few things I
don't like, but they mostly have to do with BER. My pet peeve being
that it gives the sender choices in some cases where the BER standard
should have dictated a single choice (as DER does). Giving choices
where not needed unnecessarily increases the complexity of decoders.
When you say "hard to implement" are you talking about implementation
as in implementing an ASN.1 compiler or as in manually reducing the
ASN.1 spec to code?
---
Don't tie my STT comments to ASN.1, for the two have nothing to do
with each other. When compared to the Cambridge Prefix Notation I
have no doubt that it would have been better for VISA/Microsoft to use
ASN.1, but they chose not to. That is done. At this point I seek
only a notation that is sufficiently well thought and which has
sufficient consistency to it that it is at least parsable.
Bancroft Scott