Re: [ASN.1] a doubt about CHOICE?
On Wed, 17 Jul 2002, tong wrote:
hi all
In GSM-MAP(ASN.1BER IMPLICIT),I have a doubt about CHOICE:
example 1:
Ext-SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF
Ext-SS-Info
Ext-SS-Info ::= CHOICE {
forwardingInfo [0] Ext-ForwInfo,
callBarringInfo [1] Ext-CallBarInfo,
cug-Info[2] CUG-Info,
ss-Data [3] Ext-SS-Data,
emlpp-Info [4] EMLPP-Info}
Ext-ForwInfo ::= SEQUENCE{
ss-Code SS-Code,
forwardingFeatureList Ext-ForwFeatureList,
extensionContainer [0] ExtensionContainer OPTIONAL,
...}
then begin from Ext-SS-InfoList :0x30 0xXX 0xA0(1010) (0xXX
mean length) Now the 0xA0 mean the tag of forwardingInfo,and next
octet after 0xA0 mean the length of forwardingInfo,is this right?
Yes.
example2:
SubscriberInfo ::= SEQUENCE {
locationInformation [0] LocationInformation OPTIONAL,
subscriberState [1] SubscriberState OPTIONAL,
extensionContainer [2] ExtensionContainer OPTIONAL,
...}
SubscriberState ::= CHOICE {
assumedIdle [0] NULL,
camelBusy [1] NULL,
netDetNotReachable NotReachableReason,
notProvidedFromVLR [2] NULL}
begin from SubscriberInfo: how can we encode the assumedIdle?
0x30 0xXX 0xA1(1011 subscriberState) 0xXX 0x80(1000
assumedIdle) 0x00(length of NULL)
Is the encoding of example 1 and 2 correct?
Yes.
and so example2 is longer than example1,have an extra tag of choice.
CHOICE itself does not have a tag. However, tags applied to CHOICE are
*always* EXPLICIT, even if at the beginning of the module it says that the
tag environment for the module is IMPLICIT.
Bancroft
[ASN.1] WITH-COMPONENTS creates new type or just semantically constrains?
I have questions about inner subtyping. Given these two type definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
or does it merely apply a semantic constraint to the existing type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present? For a PER encoding, the question could be
stated as, is there a presence bit (set to 0) in the bit-map preamble for
the anOptionalThing component, or is even its presence bit absent?
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Paul Long
ipDialog, Inc.
Re: [ASN.1] WITH-COMPONENTS creates new type or just semantically constrains?
Paul Long wrote:
Paul,
I guess it depends on what you mean by a new type. (The term is not
actual defined in ASN.1, but is used in the introduction and in a
normal English way when talking about defining a new type from an old
one by tagging or subtyping.)
The text is clear that tagging and subtyping (**all** forms of
subtyping) do indeed produce a new type. The text is probably
slightly unclear on whether a simple A ::= B assignment creates a new
type A from the old type B, but that is the intended view (the term
new is missing from 15.1 and 16.1, but it is clear from other cases
that a new type is intended here also).
Whether two types are the same or different matters mainly for
a) the rules on when values with one type can be used in DEFAULT as
values of the other type (or as actual parameters for a dummy parameter
defined with the other type, and
b) (if there is a value mapping between the two types) whether the
encoding of mapped values is the same in some particular encoding rule.
For the rules on a) you need to refer to what is colloquially called the
semantic model. (Formally: Rules for type and value Compatibility -
Annex B in the 2002 version.) For the rules on b), you need to refer to
individual encoding rules.
One imporant point is that for the purposes of a) above, inner subtyping
is not treated differently from any other form of subtyping. You *are*
defining a new type, but value mappings exist between the old and new
types, and values defined using one as the governor can be used as
DEFAULT values for the other (provided they are in the mapped subset).
Now we turn to b) above with BER: BER totally ignores constraints. So
the encoding of the mapped values of a constrained type are always the
same as those of the unconstrained type.
Now we turn to b) above with PER: Here it is a little more complex.
Some constraints are PER-visible (such as INTEGER (1..7) ) and affect
the encoding. Others (including UTF8String (T | F) and inner
subtyping) are *not* PER-visible. What this means is that the mapped
values encode in exactly the same way as the corresponding values in the
unconstrained type.
So
To give you a briefer answer: Your examples are best considered as
defining a new type (with a subset of the values of the old type), but
with both BER and PER the encoding of the mapped values is the same for
both the new type and the old type.
This can actually be important for inner subtyping, as one of its main
uses is to define a basic class message from a full class message,
and easy interworking between full class and basic class systems clearly
requires that encoding rules should produce the same encoding for values
that are in both the basic class and full class messages. They do!
John L
I have questions about inner subtyping. Given these two type definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
or does it merely apply a semantic constraint to the existing type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present? For a PER encoding, the question could be
stated as, is there a presence bit (set to 0) in the bit-map preamble for
the anOptionalThing component, or is even its presence bit absent?
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Paul Long
ipDialog, Inc.
--
Prof John Larmouth
Larmouth TPDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED]
Cheshire WA14 3LSTel: +44 161 928 1605
England Fax: +44 161 928 8069
Re: [ASN.1] WITH-COMPONENTS creates new type or just semanticallyconstrains?
On Wed, 17 Jul 2002, Paul Long wrote:
I have questions about inner subtyping. Given these two type definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
No.
or does it merely apply a semantic constraint to the existing type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present?
The latter.
For a PER encoding, the question could be stated as, is there a
presence bit (set to 0) in the bit-map preamble for the
anOptionalThing component, or is even its presence bit absent?
Inner type constraint is not PER-visible, so it has no effect on the
structure of PER encodings. However, in the example above the presence
bit for anOptionalThing always being zero.
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
No. It would, however, result in the presence bit for anOptionalThing
always being set to 1.
BTW, WITH ... } should be in parentheses.
-
Bancroft Scott Toll Free:1-888-OSS-ASN1
OSS Nokalva International:1-732-302-0750
[EMAIL PROTECTED] Tech Support :1-732-302-9669 x-1
1-732-302-9669 x-200 Fax :1-732-302-0023
http://www.oss.com
Re: [ASN.1] WITH-COMPONENTS creates new type or just semantically constrains?
Sorry, re my mention of possible unclarity in the A::=B and clauses
15.1 and 16.1, I missed the following in Annex B:
B.2.1 The underlying model is of types, as non-overlapping containers,
that contain values, with every occurrence of the ASN.1 Type construct
defining a distinct new type (see Figures B.1 and B.2).
This confirms the interpretation I gave below: A is a new type, defined
from B, but with the same set of values, and with a value mapping
between the two types.
John L
John Larmouth wrote:
Paul Long wrote:
Paul,
I guess it depends on what you mean by a new type. (The term is not
actual defined in ASN.1, but is used in the introduction and in a
normal English way when talking about defining a new type from an old
one by tagging or subtyping.)
The text is clear that tagging and subtyping (**all** forms of
subtyping) do indeed produce a new type. The text is probably
slightly unclear on whether a simple A ::= B assignment creates a new
type A from the old type B, but that is the intended view (the term
new is missing from 15.1 and 16.1, but it is clear from other cases
that a new type is intended here also).
Whether two types are the same or different matters mainly for
a) the rules on when values with one type can be used in DEFAULT as
values of the other type (or as actual parameters for a dummy parameter
defined with the other type, and
b) (if there is a value mapping between the two types) whether the
encoding of mapped values is the same in some particular encoding rule.
For the rules on a) you need to refer to what is colloquially called the
semantic model. (Formally: Rules for type and value Compatibility -
Annex B in the 2002 version.) For the rules on b), you need to refer to
individual encoding rules.
One imporant point is that for the purposes of a) above, inner subtyping
is not treated differently from any other form of subtyping. You *are*
defining a new type, but value mappings exist between the old and new
types, and values defined using one as the governor can be used as
DEFAULT values for the other (provided they are in the mapped subset).
Now we turn to b) above with BER: BER totally ignores constraints. So
the encoding of the mapped values of a constrained type are always the
same as those of the unconstrained type.
Now we turn to b) above with PER: Here it is a little more complex.
Some constraints are PER-visible (such as INTEGER (1..7) ) and affect
the encoding. Others (including UTF8String (T | F) and inner
subtyping) are *not* PER-visible. What this means is that the mapped
values encode in exactly the same way as the corresponding values in the
unconstrained type.
So
To give you a briefer answer: Your examples are best considered as
defining a new type (with a subset of the values of the old type), but
with both BER and PER the encoding of the mapped values is the same for
both the new type and the old type.
This can actually be important for inner subtyping, as one of its main
uses is to define a basic class message from a full class message,
and easy interworking between full class and basic class systems clearly
requires that encoding rules should produce the same encoding for values
that are in both the basic class and full class messages. They do!
John L
I have questions about inner subtyping. Given these two type definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
or does it merely apply a semantic constraint to the existing type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present? For a PER encoding, the question could be
stated as, is there a presence bit (set to 0) in the bit-map preamble for
the anOptionalThing component, or is even its presence bit absent?
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Paul Long
ipDialog, Inc.
--
Prof John Larmouth
Larmouth TPDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED]
Cheshire WA14 3LSTel: +44 161 928 1605
England Fax: +44 161 928 8069
--
Prof John Larmouth
Larmouth TPDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
RE: [ASN.1] WITH-COMPONENTS creates new type or just semantically constrains?
John,
Okay. Whew! :-)
So for my first example, PER would encode a presence bit in the preamble
bit-map for anOptionalThing, right, even though it is constrained to be
ABSENT? And it would always be set to 0 because a value for that component
is constrained to always be absent. For my second example, the presence bit
would always be set to 1 and that component would always be present, or have
a value. This is what I thought, but a colleague questioned this, which led
me to wonder...
Thanks!
Paul
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John
Larmouth
Sent: Wednesday, July 17, 2002 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [ASN.1] WITH-COMPONENTS creates new type or just
semantically constrains?
Paul Long wrote:
Paul,
I guess it depends on what you mean by a new type. (The term is not
actual defined in ASN.1, but is used in the introduction and in a
normal English way when talking about defining a new type from an old
one by tagging or subtyping.)
The text is clear that tagging and subtyping (**all** forms of
subtyping) do indeed produce a new type. The text is probably
slightly unclear on whether a simple A ::= B assignment creates a new
type A from the old type B, but that is the intended view (the term
new is missing from 15.1 and 16.1, but it is clear from other cases
that a new type is intended here also).
Whether two types are the same or different matters mainly for
a) the rules on when values with one type can be used
in DEFAULT as
values of the other type (or as actual parameters for a dummy parameter
defined with the other type, and
b) (if there is a value mapping between the two types)
whether the
encoding of mapped values is the same in some particular encoding rule.
For the rules on a) you need to refer to what is colloquially called the
semantic model. (Formally: Rules for type and value Compatibility -
Annex B in the 2002 version.) For the rules on b), you need to refer to
individual encoding rules.
One imporant point is that for the purposes of a) above, inner subtyping
is not treated differently from any other form of subtyping. You *are*
defining a new type, but value mappings exist between the old and new
types, and values defined using one as the governor can be used as
DEFAULT values for the other (provided they are in the mapped subset).
Now we turn to b) above with BER: BER totally ignores constraints. So
the encoding of the mapped values of a constrained type are always the
same as those of the unconstrained type.
Now we turn to b) above with PER: Here it is a little more complex.
Some constraints are PER-visible (such as INTEGER (1..7) ) and affect
the encoding. Others (including UTF8String (T | F) and inner
subtyping) are *not* PER-visible. What this means is that the mapped
values encode in exactly the same way as the corresponding values in the
unconstrained type.
So
To give you a briefer answer: Your examples are best considered as
defining a new type (with a subset of the values of the old type), but
with both BER and PER the encoding of the mapped values is the same for
both the new type and the old type.
This can actually be important for inner subtyping, as one of its main
uses is to define a basic class message from a full class message,
and easy interworking between full class and basic class systems clearly
requires that encoding rules should produce the same encoding for values
that are in both the basic class and full class messages. They do!
John L
I have questions about inner subtyping. Given these two type
definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
or does it merely apply a semantic constraint to the existing
type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present? For a PER encoding, the question could be
stated as, is there a presence bit (set to 0) in the bit-map
preamble for
the anOptionalThing component, or is even its presence bit absent?
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Paul Long
ipDialog, Inc.
--
Prof John Larmouth
Larmouth TPDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED]
Re: [ASN.1] a doubt about CHOICE?
hello John Larmouth and Bancroft thank you for your answers, now I have understood it much more better. thanks. === 2002-07-17 18:35:00 in your letter=== Bancroft Scott wrote: CHOICE itself does not have a tag. However, tags applied to CHOICE are *always* EXPLICIT, even if at the beginning of the module it says that the tag environment for the module is IMPLICIT. I bet some of you are saying how confusing - its as bad as XSD!. The idea was to avoid making it illegal to tag a CHOICE when you had set up a tag environment of IMPLICIT tags. May or may not have been a good decision (about 19866 vintage!) There is a tagging tutorial (with a test for you!) at: http://www.larmouth.demon.co.uk/tutorials/tagging/ if you want to try it! But you might find it easier to download: http://www.larmouth.demon.co.uk/tutorials/tagging.ppt with the same content. (Don't neglect the notes pages in the .ppt) John L = = = = = = = = = = = = = = = = = = = = tong [EMAIL PROTECTED] 2002-07-18
[ASN.1] doubts about context tag
HI all
again GSM-MAP
example:
UpdateLocationArg ::= SEQUENCE {
msi MSI,
msc-Number [1] ISDN-AddressString,
vlr-Number ISDN-AddressString,
lmsi[10] LMSI OPTIONAL,
extensionContainer ExtensionContainer OPTIONAL,
... ,
vlr-Capability [6] VLR-Capability OPTIONAL }
1 why encode 1,6,10,not continuously?
2 the order of context why not from small to big ? in this example is 1,10,6.
3 why some subtype(vlr-Number) not have context tag?
4 msc-Number not have OPTIONAL,so must presence,and so use context tag is absolutely
unneeded ?
