Peter,
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.
Or is it sufficient that they *fix* the issues you, and others from the
ongoing public review, mention?
The intention behind my mail was to point out that STT needs more work
before it can be implemented; I did not consider the possibility that
VISA/Microsoft would do other than fix the bugs in STT. Would I like
to see them use ASN.1? Absolutely, for it would allow some degree of
technology. But if I understand it correctly this is not subject
to debate, so all that I expect is that the bugs in STT will be fixed.
... ongoing public review, ....
I was not aware that there is an ongoing public review of STT. To
what degree is it public, and to what degree is STT cast in concrete?
I have other comments on CPN and its encoding rules, but they can be
viewed as enhancements, not bug fixes, so they were not included in my
previous email.
pem-dev, (and ssl-talk) ... highly politicised, undirected, non-work
lists ...
To what list should comments that do not fit in the above category be sent?
Bancroft Scott
Open Systems Solutions, Inc.