OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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 / CAP 1.2]

Has the backward-compatibility issue been reported in some TC document or

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]