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