sok>Let me give it a try. Long time since I worked with this:
"IMPLICIT TAGGING: this is where the new tag over-
rides the old tag and type information which was
carried by the old tag"
sok>Looks allright to me....
I found an example too :
Person ::= SEQUENCE {
title [0] IMPLICIT IA5String OPTIONAL,
name IA5String }
form1 is :
form1 Person ::= {
title "Sir",
name "Peter",
}
sok> Nothing wrong with this example from a first glance...
I agree that it should be coded in the following
way :
0x30 0x0c
(***) 0x80 0x03 0x053 0x69 0x72
0x16 0x05 0x50 0x65 0x74 0x65 0x72
sok> Tag - Len-Contents (TLV) looks allright...
But I don't understand how decoder should now
what ANS.1 type is mentioned in (***) ?
It is not possible to guess IA5String tag type
from 0x80 0x03 0x053 0x69 0x72 binaries ....
0x80 ---> class: context-specific
method: primitive
tag type number: 0 (???)
sok> The "a priori" knowledge of the decoder is a very
interesting discussion if cut back to how much basic
knowledge of "octets on the line" should be provided
before the transmission starts.
When I was at your level of understanding I thought
that the basic idea of ASN.1 would be to have the protocol
specification sent first from one machine to another.
The analogy for humans I guess would be to receive a call
from China. First comes a complete language course in Chinese
and later (would probably be near dead by then) - the actual
message or conversation with me - now equipped with perfect
language skills in Chinese. Impossible for a human but I guess
not completely impossible for a computer network ?
Anyway - maybe this was "shooting over the target" (proverb
here in DK)
So, realistic answer:
The protocol spec is in real life ASN.1 applications is agreed
upon while setting up the connection between the two entities.
So if you have two firms or countries setting up a connection
they will first have to agree (after having agreed on all lower
level details like who will pay the rent of the line etc...)
"we will use application protocol so-and-so version nn.nn.nn
with ammendments a,b,c and our own option d) that we think is
missing in the protocol spec as it is...."
After this agreement the spec is handed over to implementation
guys that take care of converting the protocol spec to "rules
for a decoder (and encoder)". With ASN.1 this can be done by
automated means, before ASN.1 it was done with many man-hours
of reading the agreed spec, hand-coding testing,....etc.
So summed up:
When the *** point comes in an actual transmission your decoder
will expect and 0x80 or an 0x16 - because of the OPTIONAL
in the spec. I think you have the general picture of that.
So it's that simple: A "priori" knowledge is often useful
(as remarked by Hans Christian Andersen BTW,
200th anniversary 2005)
In this case the knowledge is introduced via a building
process involving an ASN.1 compiler as front end and later
some automatic code generation in for example ANSI C.
Finally the encoder and decoder is there as one or two
functions that can be called from an outer communication
program.
I would like to receive comments on the "Chinese" idea
on [EMAIL PROTECTED] from fellow listers please.
Steen Oluf Karlsen
Soholtvej 6
Vester Vandet
DK-7700 Thisted
Danmark
Tel +45 97 97 72 72
email [EMAIL PROTECTED]
