MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: CAP Issues
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]