The V3 parser will be able to understand V1 request, if
BER (CER, DER) is used. It won't be able to understand it
if XER is used.
Marcelo Nahum (QA/EMC) 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 ?
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
_______________________________________________
Asn1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
