Thanks for sharing the perfect and complete explanation. MHO stands corrected on several counts, w.r.t ASN.1 in last 2 days.
Regards, Banibrata -----Original Message----- From: Lev Walkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 2:09 AM To: Dutta, Banibrata (STSD) Cc: Marcelo Nahum (QA/EMC); [email protected] Subject: Re: [Asn1] Question on MAP extension containers Dutta, Banibrata (STSD) wrote: > Are we absolutely sure that we can claim this, i.e. V3 parser will be > able to understand V1 request, if encoding is BER ? > > To me, the sore-point appears to be the fact that V3 is missing an > element with tag [2]. If the received PDU has a field with tag=2, > then, it'd be "ignored" at best, IMHO. It would be "ignored" by virtue > of the fact that the "..." (extension-markers) are there, and have > nothing to do with the presence of the Extension-Container field, per-se. the good thing about this specification is that mwd-Set in V1 and extensionContainer in V3 are marked as OPTIONAL. if decoder does not see the expected tag, it'll treat the encoded element as part of extension (the ellipsis). in case of V3 decoder, the decoder won't see the [4] tag and will move to processing the (zero-or-more) elements of extension (ellipsis mark), treating the mwd-Set as one of them. and yes, I am pretty sure. > Being an ASN.1 newbie, I'd love to be corrected. Waiting to hear. > > -banibrata > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Lev Walkin > Sent: Tuesday, March 06, 2007 1:00 AM > To: Marcelo Nahum (QA/EMC) > Cc: [email protected] > Subject: Re: [Asn1] Question on MAP extension containers > > > 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 >
_______________________________________________ Asn1 mailing list [email protected] http://lists.asn1.org/mailman/listinfo/asn1
