The formal phrases are "encode into a bit-field" and "encode into an octet-aligned bit-field", not "insertion of padding bits". For *unaligned* PER, *both* of the former are transmitted with no padding bits.
So for unaligned PER any ambiguity over whether the encoding produces a "bit-string" or an "octet-aligned bit-string" (and I have not checked whether the text is ambiguous - I suspect it is NOT) is irrlevant. The end result is the same - no padding bits. John L > 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 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..". > > Can someone please definitively state that padding bits are never > inserted, even in this case? > > Thanks, > > Ed Day > Principal Engineer > Objective Systems, Inc. > [EMAIL PROTECTED] > (484) 875-3020 (main) > (610) 608-4930 (mobile) > (610) 321-0361 (fax) > (877) 307-6855 (toll-free) > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Development Services) 1 Blueberry Road Bowdon [EMAIL PROTECTED] Cheshire WA14 3LS Tel: +44 161 928 1605 England Fax: +44 161 928 8069
