[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [emergency] CAP v1.2 implementation Difficulties (UNCLASSIFIED)]
-------- Original Message -------- Subject: Re: [emergency] CAP v1.2 implementation Difficulties (UNCLASSIFIED) Date: Mon, 15 Feb 2010 11:18:23 -0800 From: Rex Brooks <rexb@starbourne.com> Reply-To: rexb@starbourne.com Organization: Starbourne Communications Design To: BOTTERELL, ARTHUR C III CTR DISA JITC <Arthur.Botterell.ctr@disa.mil> References: <0143E13D-C08B-4199-BBAF-7380CC003531@grandpaham.com> <4B797378.5050906@starbourne.com> <196BDD7AA5A6E54FA086A8F4D9BD4764036A5592@vanualevu.disanet.disa-u.mil> Thanks Art, My reply will certainly get through to the list, so you can be assured that it reaches the whole TC. Just to be clear with regard to my previous statements. When I have said that I have not yet heard a compelling reason to change my vote, I probably should have been clear that at least one compelling reason would be to make a decision unanimous in favor of adopting a solution to the current situation that finds clear support. Cheers, Rex BOTTERELL, ARTHUR C III CTR DISA JITC wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > [Rex, I'm no longer on the TC mailing list, so if this doesn't get to the list, would you please forward it?] > > We included the encryption provision in CAP 1.0 out of a sense of completeness more than anything else. At that time we weren't aware of any potential conflict between signature and encryption. If we had been, I'm pretty sure we would have sacrificed encryption in favor of signatures. Encryption can be added as needed either at the transport level or by wrapping the CAP alert in an encrypted super-element, whereas a signature is tightly bound to the individual CAP message. > > In any event, we've learned from experience. A lot of folks have implemented CAP, and very few have found a need for encryption. > > In fact it sounds like we may have identified a solid use-case for the DE. In situations that actually require CAP content to be encrypted, for whatever reason, the incremental complexity and capability of the DE would clearly be justified. > > So, speaking personally, I rather like the idea of dropping support for encryption from CAP itself in the interest of facilitating digital signatures at the CAP message level. Seems like leaving encryption to the DE might reduce inconvenience for the largest number of implementers, without actually losing any capability. It's a simple, less-is-more, KISS approach. > > As for the review cycle, I don't really have standing to opine, but it sounds like there's an admissible argument for doing this on a 15-day cycle, and if someone somewhere wants to argue otherwise I'd let them make their own case. > > All that, of course, would require the TC to vote down the current motions to adopt and forward the current spec. Otherwise I'm afraid the TC could find itself in an awkward situation, facing a much longer revision cycle. > > So I hope all the TC members are paying attention and will finalize their votes accordingly. > > Again, all the above is just my personal perspective. > > - Art > > -----Original Message----- > From: Rex Brooks [mailto:rexb@starbourne.com] > Sent: Monday, February 15, 2010 11:17 AM > To: Gary Ham > Cc: emergency@lists.oasis-open.org; BOTTERELL, ARTHUR C III CTR DISA JITC; Neil C Bourgeois > Subject: Re: [emergency] CAP v1.2 implementation Difficulties > > Thanks for the prompt reply, Gary H, > > I read through the recommended change, and although I would like to hear > what Art, Jacob, Don M, Jeff W, Dave E and Lee T think, along with any > others who wish to pipe up, I think I could live with it. Either > adopting this change or dropping the <any>s in favor of the CAP v1.1 > formulation will still require a new Review Process, so unless someone > can show me how this would not require a new 60-Day Review, we're still > looking at a substantial delay. The good news is that I don't think this > would require a change in the CAPv1.2-IPAWS Profile. > > Cheers, > Rex > > Gary Ham wrote: > >> Folks, >> >> Based on Neil's difficulties with Web service compilers, Gary Timm's >> message, and on Rex Brook's response asking for a solution that does >> not break the ability to make the change a 1.2 version vice forcing >> 2.0 , I decided maybe we should in fact look at a solution that does >> work as a 1.2 change. We have tested this with out a problem and know >> that it works. The basic concept is to encapsulate the <any> tags >> within optional identified tags to isolate them from multi-namespace >> issues. (For backward compatibility we could also leave the current >> 1.1 <any> tag in place, but we would not make any use of it.) >> >> I know it is late in the game. But the following change would make >> signing work in web services and middleware validation points far more >> effectively than the current structure of CAP 1.2. That and a >> requirement that message signature use XML canonical form (as required >> in the DE) and we could guarantee success across the network. Neil has >> tested this change and it does work. >> >> >> Respectfully, >> >> Gary >> >> >> Begin forwarded message: >> >> >>> *From:* Bourgeois, Neil >>> *Sent:* Wednesday, February 03, 2010 5:13 PM >>> *To:* Gary Ham >>> *Subject:* CAPv1.2 Web-Service Implementation Challenges >>> >>> Gary, >>> We are experiencing Web-service implementation issues with the >>> CAPv1.2 schema. DM-OPEN is currently using Oracle 10g application >>> server and Oracle 10g assembler to generate Web-Services. DM-OPEN is >>> also leveraging JAXB2 and its capabilities in binding XML to Java >>> classes. >>> >>> Here are the following issues: >>> 1) With the two <any.../> tags the Oracle Assembler generates a >>> single Alert object as a SOAP Element. This will require a >>> significant amount of rework to upgrade the current CAPv1.1 >>> Web-Service to CAPv1.2. >>> 2) JAXB will not compile. Get response that "Any element has already >>> been defined". >>> >>> Recommendation to resolve these issue is to place <any.../> elements >>> within their own element. This is also a more mature schema structure. >>> >>> Have similar Web-Service implementation issues been experienced by >>> other developers? >>> >>> >>> Neil Bourgeois >>> /Cell: 703-732-6331/ >>> >>> >>> Original Schema: >>> </element> >>> <any minOccurs = "0" maxOccurs = "unbounded" >>> namespace = "http://www.w3.org/2000/09/xmldsig# >>> <http://www.w3.org/2000/09/xmldsig>" processContents = "lax"/> >>> <any minOccurs = "0" namespace = >>> "http://www.w3.org/2000/09/xmlenc# >>> <http://www.w3.org/2000/09/xmlenc>" processContents = "lax"/> >>> </sequence> >>> </complexType> >>> </element> >>> <element name = "valueName" type = "xs:string"/> >>> <element name = "value" type = "xs:string"/> >>> </schema> >>> >>> Recommended Change: >>> </element> >>> <element ref="cap:Signature"/> >>> <element ref="cap:Encoding"/> >>> </sequence> >>> </complexType> >>> </element> >>> <element name="Signature"> >>> <complexType> >>> <sequence> >>> <any minOccurs = "0" maxOccurs = "unbounded" namespace = >>> "http://www.w3.org/2000/09/xmldsig# >>> <http://www.w3.org/2000/09/xmldsig>" processContents = "lax"/> >>> </sequence> >>> </complexType> >>> </element> >>> <element name="Encoding"> >>> <complexType> >>> <sequence> >>> <any minOccurs = "0" namespace = >>> "http://www.w3.org/2000/09/xmlenc# >>> <http://www.w3.org/2000/09/xmlenc>" processContents = "lax"/> >>> </sequence> >>> </complexType> >>> </element> >>> <element name = "valueName" type = "xs:string"/> >>> <element name = "value" type = "xs:string"/> >>> </schema> >>> >>> >> Gary Ham >> Systems Architect >> FEMA Disaster Management Program >> 703-899-6241 >> >> >> Gary Ham >> http://grandpaham.com >> 703-899-6241 >> >> >> >> > > -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670 -- 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]