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 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

Yes.

> Or would alignment be done before the open type is added to the message:
>
> 1yyyyyyy  00000001  1xxxxxxx

No.  The alignment is applied to the encoded *contents* of the open type
regardless of whether PER ALIGNED or UNALIGNED is in use. There is no
alignment of the open type itself in the case of PER UNALIGNED.

> Or am I missing something?
>
> And as far as clause 16 is concerned, would OCTET STRING's ever be aligned?

Since clause 10.1 stipulates that no padding ever occurs, except possibly
at the end of complete encodings, the encoding of no type (including OCTET
STRING) is ever aligned in the case of PER UNALIGNED.

Bancroft

> 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
>
>

Reply via email to