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),
bitTen (9),
bitEleven (10),
bitTwelve (11),
bitThirteen (12),
bitFourteen (13),
bitFifteen (14),
bitNineteen (18),
bitTwenty (19),
bitTwentyone (20),
bitTwentytwo (21),
bitTwentythree (22),
bitTwentyfour (23),
bitTwentyfive (24),
bitTwentysix (25),
bitTwentyseven (26),
bitTwentyeight (27),
bitTwentynine (28)} (SIZE (15..32))
The entity sending the message encodes this data type as:
03 TAG
02 length
00 no unused bits
80 bitOne set to 1, bitTwo to bitSeven set to 0
The entity receiving the message does not accept it due to the SIZE
constraint not being respected and performs the appropriate error
handling.
Now designers of the sending entity argue that ITU-T X.690 � 8.6.2.4
and � 11.2.2 allow the encoder to encode the data type as shown
above whereas designers of the receiving entity do not share this
view and insist on the SIZE constraint being respected.
Dear Experts,
please let me know which of the above interpretations of ITU-T X.690 is correct and whether or not X.690 is incompatible to X.209 in this respect.
Thank you in advance
Ulrich Wiehe
GKS AG Gesellschaft f�r
Kommunikations Software Tel:+496621 169139
MMC2 Fax:+49 6621 169 122
Breitenstr. 57 Mobil: +49 151 14016088
D-36251 Bad Hersfeld e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-- 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
