Hi,
As far as I can see,
64 represent tag number (application 4)of batch control PDU.
79 - length of this PDU
all the rest - PDU member's values
_
Sincerely, Alex Livshitz
-Original Message-
From: devaraj[IT] [mailto:[EMAIL PROTECTED]]
Sent: Mon, March
Hi,
Here's the binary view of your file
supposedly encoded using BER:
01100100 Tag Class = "Application"
- Tag Form = "Constructed" - Tag Number = 4
0001 Short Definite Length with
121 octets for Value
0101 Tag Class
= "Application" - Tag Form = "Primitive"
Tag Number encoded using
Hi,
There seems to be some question among some groups
that we have dealt with whether PER unaligned is always unaligned. It
would seem to me that clause 7.7 is quite clear on this point that padding bits
are never inserted, but others we have dealt with claim the note in clause 16 on
On Tue, 19 Mar 2002, Ed Day wrote:
Hi,
There seems to be some question among some groups that we have dealt
with whether PER unaligned is always unaligned. It would seem to me
that clause 7.7 is quite clear on this point that padding bits are
never inserted,
It is true that padding bits
Hi Bancroft,
I'm still a bit confused. The one line that I'm not quite sure of is the
following:
This also applies to the contents of an open type, which is
always encoded in PER as if it were a complete message.
So, for example, let's say I have the following type:
MyType ::= SEQUENCE {
uOn Tue, 19 Mar 2002, Ed Day wrote:
Hi Bancroft,
I'm still a bit confused. The one line that I'm not quite sure of is the
following:
This also applies to the contents of an open type, which is
always encoded in PER as if it were a complete message.
So, for example, let's say I have
Ed Day wrote:
Hi,
There seems to be some question among some groups that we have dealt with whether
PER unaligned is always unaligned. It would seem to me that clause 7.7 is quite
clear on this point that padding bits are never inserted, but others we have dealt
with claim the note in
