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