0

I can't figure out which is the result of set operation of extensible constraints in ASN.1, like below:

A ::= INTEGER ( (1..64, ..., 100..128) INTERSECTION (1..32, ..., 33..120) )
B ::= INTEGER ( (1..64, ..., 100..128) UNION (1..32, ..., 33..120) )
C ::= INTEGER (1..64, ..., 100..128) (1..32, ..., 33..120)

What's the resultant constraint of these types?

Any help is appreciated.

Ryan
  • 800
  • 1
  • 13
  • 27

1 Answers1

1

The first two definitions are invalid since the ... can only occur at the topmost level, not nested inside multiple parentheses, so A and B are invalid definitions. See ITU-T X.680 clause 50.1 and 50.5.

C is also technically invalid since the value 120 is not within the base range of 1..64 for the "parent type". If you change the 120 to 64, then the effective constraint is as follows:

C ::= INTEGER (1..32, ..., 33..64)

ITU-T X.680 clause 50.10 has the following:

50.10 If a subtype constraint is serially applied to a parent type which is extensible through the application of an extensible constraint, value notation used within it shall not reference values that are not in the extension root of the parent type. The result of the second (serially applied) constraint is defined to be the same as if the constraint had been applied to the parent type without its extension marker and possible extension additions.

Paul Thorpe
  • 1,930
  • 17
  • 23
  • Thank you for your such clear explanation. I still doubt if there is some contradictions or that some are out-dated, as I see from example of X.691-0207 [link] (http://www.itu.int/ITU-T/studygroups/com17/languages/X.691-0207.pdf) Annex B, section B.3 (page 49): A3 ::= INTEGER ( (1..32, ..., 33..128) ^ (1..128) ), which have extension marker in nested parentheses, that is, extensible value set has been a lhs of set operation, is this legal or not, or this is the newer version of standard of ASN.1? – Ryan Nov 05 '15 at 00:11
  • Hi Ryan. I will bring this to the attention of the ASN.1 Committee to discuss updating Annex B. Please note that Annex B is an "informative" annex rather than a "normative" annex. So the rules in the body of X.680 are what is binding rather than what is in this informative annex. – Paul Thorpe Nov 05 '15 at 20:28
  • Hi Paul, are there any news regarding this yet ? – Ryan Nov 23 '15 at 04:49
  • No, nothing yet. The committee does not meet again until the end of February. – Paul Thorpe Nov 23 '15 at 23:20
  • Hello Paul, anything new about this issue? – Ryan Mar 30 '16 at 22:19
  • No, unfortunately this did not make it onto the agenda for the February meeting. I will send the link of your question to the ASN.1 Defect Editor, to see if it can be addressed and corrected via electronic correspondence rather than waiting for the next meeting. – Paul Thorpe Apr 08 '16 at 13:40