CAP Issues

[Elysa Jones <ejones@warningsystems.com>]

Greetings all!  I have accepted the task of coordinating the 
discussion/resolution of the remaining posted issues on the CAP 
Standard.  I understand items 1-12 have been resolved and offer comments 
below on the remaining.  I am new to this TC and OASIS, so please excuse my 
lack of experience with the group.

#13 - looks 'OK', but I'm no XML guru. It seems this could be easily 
corrected.  I recommend we go with the suggestion and make this a potential 
errata candidate.

#14 - seems fine, if the language is easily corrected.  I recommend we go 
with the suggestion and make this a potential errata candidate.

#15 - if the passwords are really being passed as clear-text, then unless 
someone can make a compelling argument for why they should be left in, I 
would certainly recommend removing them.  There are enough security 
problems in this world as it is, without adding more. Given the sensitivity of
the information being transmitted, we shouldn't rely on the user to 
understand whether the password is encrypted or not. Basically, if it is 
not encrypted, we should not allow it.  It is just as reasonable to suggest 
to the recipient who was expecting an un-encrypted password that an account 
just be set up  that requires no password.  Figure more folks will want to 
chime in on this.

#16 - seems like the <certainty> values should be explicitly stated as 
*ranges* instead of the way the proposal lists them. For instance:
	observed = 100%
	50% <= likely < 100%
	0% < possible < 50%
	unlikely = 0%
If the actual enumerates can be agreed upon, and/or the notion of ranges 
adopted, then this one seems like it could be readily fixed.

#17 - Category - I guess the question is, is the issue with the fact that 
the field is optional, or that the field values are free text? Personally, 
I'd prefer to see the field values become a discrete set, but keep the 
field as optional until some more compelling reason makes us want to make 
it required. The  combination of optional and free-text makes the field 
pretty useless for any form of parsing though. Since there is a version 
number associated with the spec, just fix the list of choices for category, 
with an 'other' as the catch-all, and in later versions of the spec, add 
items as needed. If the field is optional, nobody has to use it, but when 
they do, they should select from a discrete list.

#18 - I like to have this one, but as it is written, it is not specific 
enough. Perhaps it can be tabled until a recommend list of <responseType> 
items or <instruction> items can be found that are somewhat more 
industry-standard?

This is a start at working through items 13-18.  Please respond and let's 
try to get some consensus for voting by the July 27 TC.

Regards,
Elysa Jones