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 alphabetThis 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
