[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Special Meeting Friday: Fwd: CAP spec questions
Hi EM-Msgers, Elysa, Art, Since no one has expressed an opinion about this, I'm going to schedule a meeting Friday at 11:00 a.m. Eastern Time because its too late today, I can't fit it in tomorrow, and there's an Adoption SC meeting at 12:00 p.m. Eastern, so those of us with that on our calendar should have a built-in reminder. To repeat: we voted as a subcommittee to recommend CAP v1.2 to the TC for a vote for Committee Draft and a 60-Day Public Review at next week's TC meeting. I asked the opinion of the group about a special meeting, and outside of Jacob, received none. I don't think it is responsible of us to delay this and there actually are a couple of items below on which we should reach some agreement on the record. I also think that we should not delay continuing work on the EDXL-HAVE errata items at next week's EM-Msg SC meeting. For Friday: I think the second bullet and the fourth bullet need consensus because the second bullet allows multiple signatures but not multiple EncryptedData components and I want to be sure we're on board with why this is so; and, the fourth bullet removes the <msgType> Cancel from the note element advice in the Data Dictionary while adding <status> Exercise. Jacob and Art have had an online conversation about this, but I think the result was that issues related to Cancel need to be in 2.0 bucket. -add the phrase "one or more Signature elements" as Jacob recommends; -change the schema to specify that only 1 (one) EncryptedData element is allowed, AND change 3.3.2 Security Note appropriately (we need the language here); -move the DateTime Data Type to the Normative References section; -change specification of <status> in Data Dictionary on page 14 to read ", exercise Identifier SHOULD appear in <note>"; and -change specification of <note> to read "The message note is primarily intended for use with <status> Exercise and <msgType> Error." (just making the order reflect the order they occur in the document). Note: If there is a hue and cry that this not doable, we can, of course, revert to plan B: wait until next Tuesday, after the TC meeting, and delay the release of CAP v1.2 for approval as a Committee Draft until the next TC meeting, while we work these issues and probably delay reconnecting to the EDXL-HAVE issues. Jacob, Can you reply with your thoughts and let us know if you can upload another version that reflects these bullets so we can review it before Friday? Cheers, Rex P.S. Jacob, I don't think there is a strict rule about how to handle revision history within a version number v across version numbers. I'd just include those changes related to this version, 1.2. Date: Mon, 20 Apr 2009 17:27:57 -0400 From: Jacob Westfall <jake@jpw.biz> To: rexb@starbourne.com Subject: CAP spec questions Organization: JPW X-Nonspam: Statistical 65% Hi, Some spec editing questions regarding CAP 1.2. I've been going through and cleaning up the draft 04 of the CAP 1.2 spec, fixing the table of contents, correcting puncuation, whitespce, numbering, etc. Nothing substantive, all editorial fixes but will it need to be voted on again when this cleanup is done? In the revision history at the bottom, should this capture revisions to past versions like 1.0 and 1.1 or is it just revisions to 1.2 itself? The DateTime Data Type is currently in the Terminology section but I thought it might belong in the Normative References section since we are stating that this Data Type formatting must be used in the appropriate element values, thereby being normative. I noticed 2 potential errors in doing this further review. The first is that section 3.3.3 on Security and Encryption states that only 1 EncryptedData element is allowed and 1 Signature element. This is wrong, it should be 1 EncryptedData and multiple Signature elements. So wording could be added to say "one or more Signature elements". The schema should also be updated to reflect that only 1 EncryptedData element be allowed but keep the multiple Signature elements that is already in there now. The second is page 14 element name status. For status "Exercise" it says "exercise identifier should appear in <note>". This probably should be "SHOULD" instead. It would also mean updating the text for the note element to reflect that "The message note is primarily intended for use with <msgType> Error and <status> Exercise" Again all minor changes and not really substantive but I wanted to know how best to handle them. Thanks, -- jake@jpw.biz -- -- 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]