[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Fwd: [emergency] Questions on ASN.1 and IPAWS Profile / CAP1.2]
Thanks Alessandro, I appreciate the explanation. Happy Holidays, Rex Alessandro Triglia wrote: > Has the backward-compatibility issue been reported in some TC document or > email? > > Without having it at hand right now, I'll make the following observation. > > The X.694 standard, which was used to create the ASN.1 schemas in CAP 1.1 > and CAP 1.2, specifies a rigorous mapping from XML Schema to ASN.1. The > mapping rules are so rigorous that they ensure that one can seamlessly > translate between an XML encoding and a PER encoding just by applying the > standard encoding rules (PER and EXER) to the ASN.1 schema. This makes it > easy to build an application that can handle both encodings, so long as the > application uses conforming ASN.1 encoder/decoders. > > The downside of following strict mapping rules from XML Schema to ASN.1 is > that when the original XML schema is modified, the new ASN.1 schema may not > be backward-compatible with the old ASN.1 schema. This can happen even in > case of seemingly minor changes such as a new item being added to an > enumeration, or a required attribute or child element becoming optional, or > vice versa. In the case of CAP 1.2 vs. 1.1, the changes made to the XML > schema cause the PER encodings to change significantly. > > But again, the upside of using X.694 is that applications will be able to > easily translate back and forth between ASN.1/PER and XML. > > We cannot just have both benefits, and the X.694 standard determines which > one we can have. > > Alessandro > > > >> -----Original Message----- >> From: Rex Brooks [mailto:rexb@starbourne.com] >> Sent: Tuesday, December 22, 2009 23:16 >> To: tony@yaanatech.com >> Cc: TIMOTHY.D.GILMORE@saic.com; >> emergency@lists.oasis-open.org; MARTENA.M.GOOCH@saic.com; >> Olivier DUBUISSON; Elysa Jones; Jacob Westfall >> Subject: Re: [Fwd: [emergency] Questions on ASN.1 and IPAWS >> Profile / CAP 1.2] >> >> Thanks Tony, >> >> I misstated myself. I didn't mean to give the impression >> that I thought >> ASN.1 was mainly aimed at European communities, but that the >> ASN.1 representation of CAP 1.1 was. That was why I said >> that this was the "first time I heard ASN.1 encoded CAP >> messages in relation to any US-specific implementation..." >> >> That was my perception of it, but I was not involved with >> that effort except that it occurred at the same time as the >> CAP 1.1 errata, which I did work on, was working its way >> through the OASIS process. >> >> I don't think the current situation is related to The >> CAP-IPAWS profile except insofar as it prompted the effort to >> update CAP to 1.2 with the new <avoid> response type. I have >> added Elysa Jones and Jacob Westfall to this message, and I >> would like to draw everyone's attention to Tim Gimore's >> message to the EM TC email list this morning >> http://www.oasis-open.org/apps/org/workgroup/emergency/email/a >> rchives/200912/msg00023.html >> because this is the message to which I was responding. >> >> At this point it is probably best if I don't dig myself in >> any deeper. I invite Elysa and/or Jacob to weigh in if they >> wish. As the principle author of CAP v1.2, Jacob is most >> knowledgeable. We have followed the OASIS TC Process >> scrupulously and provided ample opportunity for issues such >> as those which have been brought up recently to be addressed. >> However, the ASN.1 backward compatibility issue surfaced >> after the initial 60-Day Public Review, so were out of scope >> for the second 15-Day Review which recently ended, and after >> which we have continued to move CAP v1.2 forward. >> >> Best Regards, >> Rex >> >> >> >>> Hi Rex, >>> >>> My ITU-T colleague Olivier Dubuisson forwarded you email message. >>> My group in ITU-T is responsible for X.1303 - which not only >>> globalizes the CAP specification, but also usually provides a much >>> more efficient and compact ASN.1 version, as well as a new global >>> identifier space for its use. The namespace includes uses for >>> parties, messages and policies, and was done with multiple >>> >> agencies, especially including the WMO. >> >>> As a side note, I'm U.S. based, as well as a former SAIC >>> >> employee and >> >>> appointed member of the FCC WARN Act advisory committee. >>> >>> ASN.1 is definitely not a "European thing." In fact, it >>> >> was developed >> >>> in the 1980s as a global standard and for years was >>> >> mandated by both >> >>> DOD and the U.S. telecommunications industry. I'll admit to not >>> following current IPAWS activity, but there is no reason >>> >> why the ASN.1 >> >>> equivalent could not be used, as long as translations were >>> >> ensured at >> >>> requisite interfaces where the XML versions are necessary. >>> >> The ASN.1 >> >>> version of CAP is definitely much more compact - which work in its >>> favor in both one-to-many architectures, as well as small >>> >> form factor >> >>> devices. >>> >>> Hope this helps, >>> --tony >>> >>> >>> >>>> -------- Original Message -------- >>>> Subject: Re: [emergency] Questions on ASN.1 and IPAWS >>>> >> Profile / CAP >> >>>> 1.2 >>>> Date: Tue, 22 Dec 2009 06:00:11 -0800 >>>> From: Rex Brooks <rexb@starbourne.com> >>>> Reply-To: rexb@starbourne.com >>>> Organization: Starbourne Communications Design >>>> To: Gilmore, Timothy <TIMOTHY.D.GILMORE@saic.com> >>>> CC: emergency@lists.oasis-open.org, "Gooch, Martena M." >>>> <MARTENA.M.GOOCH@saic.com> >>>> >>>> Hi Tim, >>>> >>>> This is the first time that I've heard ASN.1 encoded CAP >>>> >> messages in >> >>>> relation to any US-specific implementation, so I'll have to plead >>>> ignorance on this. I was under the impression that while this is >>>> allowable, e.g. not specifically discouraged, in US-Canada, it was >>>> mainly aimed at European countries/communities. >>>> >>>> >>> >>> >> -- >> Rex Brooks >> President, CEO >> Starbourne Communications Design >> GeoAddress: 1361-A Addison >> Berkeley, CA 94702 >> Tel: 510-898-0670 >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >> oups.php >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]