47.4.2 says:
>>>>>>>>>>>>>>>>>
All values specified in the "ValueRange" are required to be in the root of the parent type.
<<<<<<<<<<<<<<<<
(Root here means the extension root, and is not relevant to the present dscussion.)
Thus INTEGER (1..20)(1..30) is already illegal.
However, I agree that an example under 47.4.2 something like the above might be useful in a future version. (Or possibly a reference to G.4.2.3 from here).
Note however G.4.2.3, where we have:
>>>>>>>>>>>>>>>
The serial application of constraints is (for complex cases) not the same as a set arithmetic intersection, even when there is no extensibility involved. Firstly, the environment in which MIN and MAX are interpreted, and secondly the abstract values that can be referenced in the second constraint are very different in serial application from the situation where the two constraints are specified as an intersection of values from a common parent.
<<<<<<<<<<<<<< With the following example:
>>>>>>>>>>>>
A2 ::= INTEGER (1..32) (MIN .. 63)
-- MIN is 1, and 63 is illegal
<<<<<<<<<<<I think this makes the situation very clear.
John L
Yhu
WangHao wrote:
I agree with the opinion that OCTET STRING (SIZE(1..20))(SIZE(1..9)) is a new constrained type.
Recently, I reinforce our ASN.1 complier tool and came across the similiar problem.
Some engineers in testing department of our Huawei company often define the folloing ASN.1 syntax:
Byte INTEGER(0..255)
Bit3 Byte(0..7)
If we expand the constrained type Bit3 we can get the cumbersome form:
Bit3 INTEGER(0..255)(0..7).
To deal with that, I review the X.680 and come to a conclusion that the constraint of Bit3 is
the intersection of (0..255) and (0..7). However, I also put some constraints to our ASN.1 compiler that the range of the latter constraint set must be subset of that of the former. In other
words, we can only shrink the range and can not expand the range.
In my opinion, this constraint usage case should be made clear in X.680.
WangHao
Hideki Shingu wrote:
----- Original Message ----- From: "Hideki Shingu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 04, 2004 3:19 PM
Subject: [ASN1] Re: [ASN.1] 3GPP TS24.080 forwardedToNumber IE
Thank you for your kindly comments.
We don't know why the definers choose such a way of discription, but we should assume that "OCTET STRING (SIZE(1..20))" is new Type difinition, shouldn't we?
So now, a new question about that syntax comes up. How is that syntax,
"forwardedToNumber OCTET STRING (SIZE (1 .. 20 )) (SIZE (1 .. 9 ))", encoded to by BER? Now I think as follws,
ã0x04(T) 0x02(L) 0x01 0x02(V) ã0x04(T) 0x03(L) 0x03 0x04 0x05(V) ........ (up to 9th column)
where Type value which shows "OCTET STRING" is 0x04. The maximum value of (V) is 20, and the maximum value of column is 9.
If the BER encoded pattern is not correct, should new Type value be assigned to ConstrainedType? Or, is there a correct encoded pattern for above syntax?
Could you please give me some clues.
Thanks.
Hideki SHINGU ([EMAIL PROTECTED])
Core Technology Development Center Panasonic Mobile Communications Co.,Ltd. TEL:+81-45-939-1054 Ext.7-352-2132
John Larmouth wrote:
I completely agree that this is what the syntax means!
But why the definers chose this cumbersome way of saying SIZE 1..9, if that is what they intended, is a more difficult question, and makes one think that they did not, in fact, **intend** this meaning.
Someone else closer to 3GPP may be able to shed more light on this.
John L
Ramaswamy R - CTD, Chennai. wrote:
Hi,
The type "OCTET STRING (SIZE (1 .. 20 )) (SIZE (1 .. 9 ))" specified, falls under the notation -
ConstrainedType ::= Type Contrstraint
This notation is used twice in the above type specified. "SIZE(1..20)" is the Constraint for the Type: "OCTET STRING" and "SIZE(1..9)" is the Constraint for the Type: "OCTET STRING (SIZE(1..20))". When such situations are encountered it evaluates to the Constraint effectively being the intersection of the two constraints. IN this case effectively it shoudl evaluate to a single constraint - "SIZE(1..9)".
Regards Ramaswamy R Member Technical Staff HCL Technologies Ltd Chennai - 600026
"Do or do not. There is no try." - Yoda
Disclaimer:
This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
-----Original Message----- From: Hideki Shingu [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 6:55 AM To: [EMAIL PROTECTED] Subject: [ASN.1] 3GPP TS24.080 forwardedToNumber IE
I am a newcomer to this ML. Please forgive me if my question is not suitable for the force of this ML.
I have a question about ASN.1 syntax in 3GPP TS24.080. The syntax bothering me is as follows,
forwardedToNumber [5] IMPLICIT OCTET STRING (SIZE (1 .. 20 )) (SIZE (1 .. 9
)) OPTIONAL,
I don't understand why there are no Type difinition between "SIZE"s. I can't find this syntax in ITU-T specificaiton. I think this means as
follows,
ïforwardedToNumber SEQUENCE SIZE(1 .. 9) OF (OCTET STRING(SIZE(1 .. 20)))
Is that right? or not?
If anyone know this, please let me know. If this subject has already
discussed, please tell me where I should go to see the process of this discussion.
Thanks.
Hideki SHINGU ([EMAIL PROTECTED])
Core Technology Development Center Panasonic Mobile Communications Co.,Ltd. TEL:+81-45-939-1054 Ext.7-352-2132
-- 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
_______________________________________________ ASN1 mailing list [EMAIL PROTECTED] http://lists.asn1.org/mailman/listinfo/asn1
------------------------------------------------------------------------
_______________________________________________ ASN1 mailing list [EMAIL PROTECTED] http://lists.asn1.org/mailman/listinfo/asn1
-- 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
_______________________________________________ ASN1 mailing list [EMAIL PROTECTED] http://lists.asn1.org/mailman/listinfo/asn1
