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 {
a BOOLEAN,
b TYPE-IDENTIFIER.&Type
}
and let's say we have encoded a boolean TRUE value for the open type field
which I believe would be:
00000001 1 xxxxxxx
length value padding
So would the final encoding now look like (assuming TRUE for the first
boolean):
10000000 11xxxxxx xyyyyyyy
^ length ^
! value2
value 1
x = inner type padding
y = outer type padding
Or would alignment be done before the open type is added to the message:
1yyyyyyy 00000001 1xxxxxxx
Or am I missing something?
And as far as clause 16 is concerned, would OCTET STRING's ever be aligned?
Regards,
Ed
----- Original Message -----
From: "Bancroft Scott" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 19, 2002 4:58 PM
Subject: Re: [ASN.1] Is PER unaligned always unaligned?
> 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 are never inserted in the case of PER
> unaligned, except in one case. See X.691 clause 10.1 where it makes it
> clear that padding bits are inserted when the encoding is that of the
> outermost type. In other words, when the entire message has been encoded,
> pad bits are added if needed to have the completed message end on an octet
> boundary. This also applies to the contents of an open type, which is
> always encoded in PER as if it were a complete message.
>
> > but others we have dealt with claim the note in clause
> > 16 on OCTET STRING's indicates padding bits should be inserted because
> > it does not discern between aligned and unaligned forms. It simply
> > states that "Octet strings of fixed length less than or equal to two
> > octets are not octet aligned. All other octet strings are aligned.
> > etc..".
>
> In the above you are pointing to the tutorial note at the top of clause
> 16, "Encoding the octetstring type", which is simply meant to give a
> tutorial summary of what the clause covers in depth. Please read the
> normative text - the body of clause 16. Note that it consistently speaks
> of addition of the octet string value to either the field-list as a
> bit-field or an octet-aligned bit-field. Once the field-list has been
> fully created, the fields within it are concatenated with or without
> padding to form the complete encoding, as specified by clause 10.1.
> Clause 10.1.2 makes it clear that for the UNALIGNED variant of PER no
> padding ever occurs, except for the encoding of the outermost type itself.
>
> It is also useful to read the definition of "field-list" in clause 3.7.12,
> as well as the clarifying note attached to it. This clause makes a clear
> distinction between adding an encoding into the field-list as either
> aligned or unaligned, and creation of the complete encoding where pad bits
> are or are not inserted, as specified by clause 10.1
>
> -------------------------------------------------------------------------
> Bancroft Scott Toll Free :1-888-OSS-ASN1
> OSS Nokalva International:1-732-302-0750
> [EMAIL PROTECTED] Tech Support :1-732-302-9669
x-1
> 1-732-302-9669 x-200 Fax :1-732-302-0023
> http://www.oss.com
