The one open point is different handling of this case in ASN.1 standards. So if that's an older protocol using ASN.1 standard 208,209 , the adding and removing of zeros (trailing bits) is not allowed. So for the decoder (in this case) would means invalid value and decoding error when the SizeConstraint is violated. Is this right?
Ed --- John Larmouth <[EMAIL PROTECTED]> wrote: > There is absolutely no reason why any tool should > not enforce > constraints, whatever the encoding that is in use, > and whatever the form > of a constraint - even a comment, if the tool is > clever enough. > > That was not the issue. The issue was not whether > you could transmit > abstract values outside the size constraint - you > can't (legally), in > BER or in PER or in DER or in XER or anyhwere else. > The issue was > whether the given encoding was a valid BER encoding > for a value in the > range of the size constraint, and it was. > > John L > > > Phillip H. Griffin wrote: > > I don't disagree in a purely "technical" sense. > But I do agree > > that it is up to the protocol that uses ASN.1, and > not to ASN.1 > > alone, as to what is actually a valid message. > > > > The constraint was intentionally placed in the > message definitions. > > I would assume that this rule was meant to be > enforced. But where > > this rule is enforced is a key issue. > > > > ASN.1 tool vendors and ASN.1 application providers > may provided > > a "strict" switch that causes the constraints to > be enforced so that the > > protocol rules are obeyed as written, even if the > ASN.1 standards > > do not require the constraints to be enforced in a > given encoding > > rules. > > > > The encoder tool obeying the ASN.1 as written > would then detect the > > encoding to be in error. But a 'vanilla' coder > tool might choose to just > > obey the ASN.1 standards and leave it to the > underlying application > > that uses the coder tool to enforce the rest of > the protocol. > > > > That is the underlying application, not the coder > tool itself, may be > > required to enforce the constraint specified in > the protocol. Clearly some > > piece of code must enforce the protocol as written > or the constraint should > > never have been written at all. > > > > A tool vendor may allow his tools to "see" the > constraints and enforce > > them even in BER. This takes the burden off of the > underlying application > > and places the burden for enforcing the protocol > on the coder tool. > > > > The SET protocol was defined such as this using > ASN.1 and encoded in > > DER. A set of guidelines was written for testers > that made it clear what > > errors had to be detected by implementers of the > protocol. And in some > > cases, the guidelines made it clear that the coder > tool was required to > > enforce some protocol behavior that was outside of > the scope of the > > ASN.1 standards. > > > > This situation sounds like the SET case and would > seem to need some > > guidance for implementers as to what is and what > is not a valid protocol > > message - not merely what is valid ASN.1. > > > > Phil Griffin > > > > > > John Larmouth wrote: > > > >> This one is very tricky. > >> > >> Trailing zero bits are not significant when there > are named bits. > >> > >> The size constraint has not been violated by the > encoded value. What > >> has been transferred by the encoding, in abstract > value terms is a > >> *set* of values of infinite length, all with only > the fist bit set and > >> all other bits set to zero. (DER text - > canonical - on this stuff > >> gets interesting, if you read it!) All else is > encoders options. But > >> the SIZE constraint does indeed restrict the > *abstract* values > >> (independently of the named bits specification), > and so what is being > >> sent is !1000000000000000', '1000000000000000', > etc up to > >> '10000000000000000000000000000000000000000', > **all of which carry the > >> same semantics**. > >> > >> (I hate this stuff - every time we have made a > new version since 1984, > >> we have tinkered with the text to try to get a > clean model and > >> specification. Basically, the named bits stuff > was fundamentally > >> flawed way back in 1982. But I believe that what > I say above fits the > >> current text - and indeed most earlier text. The > encoding is valid.) > >> > >> In specific reply to Ed: the restriction of the > size constraint is on > >> the abstract values. Not on the way they are > encoded. > >> > >> John L > >> > >> > >> Ed Day wrote: > >> > >>> It is my opinion that the size constraint in > this case must be > >>> respected; otherwise, it has no meaning. > Clearly, the person who > >>> wrote this definition wanted the bit string to > be between 15 and 32 > >>> bits in length, otherwise the size constraint > would not have been > >>> added. As to precise language in the standards > stating this, I could > >>> not find any. > >>> > >>> Regards, > >>> > >>> Ed Day > >>> Objective Systems, Inc. > >>> REAL WORLD ASN.1 AND XML SOLUTIONS > >>> Tel: +1 (484) 875-3020 > >>> Fax: +1 (484) 875-2913 > >>> Toll-free: (877) 307-6855 (USA only) > >>> mailto:[EMAIL PROTECTED] > >>> http://www.obj-sys.com > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> From: Wiehe Ulrich > <mailto:[EMAIL PROTECTED]> > >>> To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >>> Sent: Friday, February 28, 2003 4:27 AM > >>> Subject: [ASN.1] Question on BER > >>> > >>> Dear ASN.1 experts > >>> > >>> In order to solve an interoperability > problem resulting from > >>> different interpretations of ITU-T X.690, > your help on the following > >>> question is very much appreciated: > >>> > >>> A BER encoded message contains a data > type for which the > >>> abstract > >>> syntax is defined as > >>> > >>> DataType ::= BIT STRING { > >>> > >>> bitOne (0), > >>> > >>> bitTwo (1), > >>> > >>> bitThree (2), > >>> > >>> bitSeven (6), > >>> > >>> bitEight (7), > >>> > >>> bitNine (8), > >>> > >>> bitFour (3), > >>> > >>> bitFive (4), > >>> > >>> bitSix (5), > >>> > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
