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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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