Thank you very much for your answers. The issue is clear now.
Best regards,
Marcelo
________________________________
From: Ramaswamy R [mailto:[EMAIL PROTECTED]
Sent: March 6, 2007 2:02 AM
To: Marcelo Nahum (QA/EMC)
Cc: [email protected]
Subject: Re: [Asn1] Question on MAP extension containers
On 3/6/07, Marcelo Nahum (QA/EMC) <[EMAIL PROTECTED]>
wrote:
Hi Ramaswamy,
Thanks for your quick response. I copied the example
again since the V3
version is a bit different. As you can see the entry
mwd-set was
removed, and there is an extension container instead.
Will in this case
a V3 parser understand a V1 request if the entry mwd-Set
is present in
the request ?
Per the spec in V3 you have specified, the parser does not
expect tag [2]. It only understands those of the fields imsi,
locationInfoWithLMSI and extensionContainer (if present). A V1 request
could contain mwd-Set with tag [2]. So a V3 parser would not able to
interpret mwd-Set in the request as the specification does not list a
field with tag [2]. It would be considered as an item following the
extension (thinking that its probably from a higher version than V3 ;)
).
The point I am making is that since in the spirit of ASN.1
language this is not how extensions are to be used, interoperability b/w
versions is not guranteed. As Lev pointed out, a V3 out decoder would
probably be able to parse the request (although ignoring mwd-Set if
present), but our V3 guy would not be able to interpret the mwd-Set
data.
If your question is as to whether V3 can decode a V1 request
message, and you are fine with him ignoring the information in mwd-Set
field, then YES. But a V3 decoder would not be able to interpret the
information in mwd-Set (if present) of a V1 request as a V1 parser would
do. When the mwd-Set field ain't present in the V1 request, there
wouldn't be any issues :).
Hope this makes some sense to you.
Cheerios
Ramaswamy
Disclaimer: I am aware of the ASN.1 language and what things
mean there to a certain extent. As I do not have any hands-on experience
in implementations of protocols as such, there could be subtle nuances /
my misunderstandings due to which my argument could be wrong :D.
--
"Chaos is the rule in nature, not an exception"
http://ramaswamy.r.googlepages.com
V1:
RoutingInfoForSM-Res::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0]
LocationInfoWithLMSI,
mwd-Set [2] BOOLEAN OPTIONAL,
...}
V3:
RoutingInfoForSM-Res ::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0] LocationInfoWithLMSI,
extensionContainer [4] ExtensionContainer
OPTIONAL,
...}
Thanks again,
Marcelo
________________________________
From: Ramaswamy R [mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: March 5, 2007 12:53 PM
To: Marcelo Nahum (QA/EMC)
Cc: [email protected]
Subject: Re: [Asn1] Question on MAP extension
containers
Hi,
Extension are used to say that future version may
contain more
data than what is there at present. I.e. V3 will have
the data from V1,
V2 and it additions more from V3. I believe that the
definition must
have been as follows -
V1: RoutingInfoForSM-Res::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0]
LocationInfoWithLMSI,
mwd-Set [2] BOOLEAN OPTIONAL,
...}
V3: RoutingInfoForSM-Res ::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0]
LocationInfoWithLMSI,
mwd-Set [2] BOOLEAN OPTIONAL,
...
extensionContainer [4]
ExtensionContainer
OPTIONAL,
}
The extension marker helps ensure backward
compatibility as
follows. Since RoutingInfoForSM-Res in V3 has the fields
of V1 when a V1
based encoder / decoder intercepts a message from V3 it
only interprets
the fields that it understands and skips the rest. Thus
this does not
break the way older versions interpret the data from
newer versions.
On 3/5/07, Marcelo Nahum (QA/EMC)
<[EMAIL PROTECTED]>
wrote:
I'm quite new to ASN.1 and have a
question related to
extension containers.
Are extension containers used also for
backward
compatibility ?
For example, regarding the different
versions of the GSM
MAP standard (29.002), extension containers seem to be
there where an
old version of the standard had a deprecated entry.
V1:
RoutingInfoForSM-Res::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI
[0]
LocationInfoWithLMSI,
mwd-Set [2] BOOLEAN
OPTIONAL,
...}
V3:
RoutingInfoForSM-Res ::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0]
LocationInfoWithLMSI,
extensionContainer [4]
ExtensionContainer
OPTIONAL,
...}
If I parse a V1 request using a V3
parser, will the
extension container contain the mwd-Set value ?
IMHO this ain't a valid usage of extension marker
across
versions of an asn.1 spec. If you actually intended the
one I mentioned
above, then YES.
In my understanding, a V3 encoder / decoder
receiving a V1 data
will fail saying that expected field (with tag [4]) was
not there unless
the field in the extension was OPTIONAL. This is where
you can use the
ExtensionAndException notation to raise exceptions when
the fields past
the extension marker are not found.
Hope this throws some clarity to the problem you
stated.
Cheerios
Ramaswamy
Thank you in advance,
Marcelo
_______________________________________________
Asn1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
--
"Chaos is the rule in nature, not an exception"
http://ramaswamy.r.googlepages.com
<http://ramaswamy.r.googlepages.com>
_______________________________________________
Asn1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
