To add more information to the original question: the problem we were running into was how to interpret this in terms of a PER encoding. Should an extension bit be present or not? It now appears the answer to this is "yes, it should".
What was confusing is that the way we implemented the ASN.1 grammar caused "SIZE (1..160)" to collapse into a subtype value which eventually turned into a RootElementSpec which pushed us up to the following rule: ElementSetSpecs ::= RootElementSpec | RootElementSpec "," "..." etc. >From this perspective, it looked like the "SIZE (1..160)" was one constraint and the "..." was saying other constraints might follow in the future. I don't know if it is possible to say some thing like "(SIZE (1..160) ,..., FROM ("ABCD"))", but the grammar does not prevent it (perhaps the wording in the text does someplace). We did find the examples in X.691 which make this clearer and are now using those to make sure our processing for complex cases is correct. As Bruno mentioned, the specification in question was changed to express the constraint in the more normal way, so I guess we were not the first to run across this problem. Regards, Ed Day ----- Original Message ----- From: "John Larmouth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 26, 2004 12:17 PM Subject: Re: [ASN.1] Question on SIZE constraint syntax > I was asked to forward this extracts from the joint meeting of the ITU-T and > ASN.1 Rapporteur Groups meeting in Paris this week. > > If aditional comments on this subject are received during the meeting, they will > be considered. > > >>>>>>>>>>>>>>>>> > Resolving the query about the extensibility marker > > Homework was given for Monday evening to the Rapporteur to relay the following > part of the minutes to the originator of the query, and to invite comments > before the end of the meeting. > > The query was as follows: > > >++++> > We have a question on size constraint syntax. In the RANAP specification, the > following declaration exists: > > TransportLayerAddress ::= BIT STRING (SIZE (1..160), ...) > > According to X.680, an extensible size should be written as follows: > > (SIZE (1..160,...)) > > We are wondering how the above definition should be treated. X.680 Annex G > gives several examples of extensible situations, but this one does not appear to > be covered. It would appear to us that in the case above, the ... is indicating > that additional constraints can be added in the future and would not apply to > the 1..160 range. How should this be interpreted? > > <++++< > > In discussion of this, attention focussed first on X.680, 46.3. Two points were > made related to bullet a: > > 1. The phrase "outer level" is not well defined. It would be expected to refer > to an ellipsis textually present in the BNF definition of "Elements". However, > there is no such ellipsis in that BNF. > > 2. It is curious that 46.3 refers to "Elements" (without any forward cross > reference), but the BNF for "Elements" only appears in 46.5. > > A tentative conclusion was drawn that the use of "Elements" was a typo for > "ElementSetSpecs" defined in 46.1, which does allow an ellipsis at the "outer > level" in alternatives 2 and 3 of the BNF. > > Thus in addition to correcting the typo, the term "outer level" should be > replaced by reference to these two alternatives. ***Further addition and > discussion of this tentative conclusion is needed, with a view to a possible > defect report.*** > > It was however recognized that this problem was not directly related to the > original query. > > Attention then focused specifically on extensibility following the right > parenthesis of a size constraint. The following example (for character strings) > was considered relevant: > > A12 ::= IA5String (SIZE(1..10) ^ FROM("A".."D"), ...) > -- A12 has an extensible effective size constraint of SIZE(1..10,...) > -- and the alphabet is the entire IA5String alphabet > > This example is fully supported by the normative text for character string > encodings. It would imply: > > A12bis ::= IA5String (SIZE(1..10), ...) > -- A12bis has an extensible effective size constraint of SIZE(1..10,...) > > Again, the normative text supports this. This would further imply > A12ter ::= BIT STRING (SIZE(1..10), ...) > -- A12ter has an extensible effective size constraint of SIZE(1..10,...) > > The group agreed that this was the intended encoding, but that the text for BIT > STRING encodings did not clearly specify this, and needed to be aligned more > closely with the text for character string encodings. It was also noted that > the text for OCTET STRING encodings was also slightly different from these. > > *** Further discussion of these conclusions is needed, and a defect report will > be raised at the end of this meeting to ensure that such discussion take place. *** > > The "proposed solution" in the defect report will be as outlined above. > > <<<<<<<<<<<<<< > > I would add the additional comment (in repoly the later part of the query) that > relaxation of constraints by an extension is just that - relaxation (an OR, or > UNION, operation). So any constraints following the ellipsis would not affect > the ability to legally encode any bitstring which was in the size range 1 to > 160, but might (for example) require that anything outside that range be a > specific set of listed bitstring values. > > John L > > > > Ed Day wrote: > > > Hi, > > > > We have a question on size constraint syntax. In the RANAP > > specification, the following declaration exists: > > > > TransportLayerAddress ::= BIT STRING (SIZE (1..160), ...) > > > > > > According to X.680, an extensible size should be written as follows: > > > > (SIZE (1..160,...)) > > > > We are wondering how the above definition should be treated. X.680 > > Annex G gives several examples of extensible situations, but this one > > does not appear to be covered. It would appear to us that in the case > > above, the ... is indicating that additional constraints can be added in > > the future and would not apply to the 1..160 range. How should this be > > interpreted? > > > > Regards, > > > > Ed Day > > Objective Systems, Inc. > > REAL WORLD ASN.1 AND XML SOLUTIONS > > Tel: +1 (484) 875-9841 > > Fax: +1 (484) 875-9830 > > Toll-free: (877) 307-6855 (USA only) > > mailto:[EMAIL PROTECTED] > > http://www.obj-sys.com > > > > > > -- > Prof John Larmouth > Larmouth T&PDS Ltd > (Training and Protocol Development Services Ltd) > 1 Blueberry Road > Bowdon [EMAIL PROTECTED] > Cheshire WA14 3LS > England > Tel: +44 161 928 1605 Fax: +44 161 928 8069 > > >