OASIS Emergency Management TC

  • 1.  CAP Issues

    Posted 07-13-2004 14:46
     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]