OASIS Emergency Management TC

  • 1.  [OASIS Issue Tracker] (EMERGENCY-33) Remove Ack and Error msgTypes

    Posted 11-21-2014 13:09
    [ https://issues.oasis-open.org/browse/EMERGENCY-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51541#comment-51541 ] Steve Hakusa commented on EMERGENCY-33: --------------------------------------- This proposal arises out of https://issues.oasis-open.org/browse/EMERGENCY-31 As will be clarified from that issue, the meaning of "Cancel" is essentially to repudiate an incorrect message. CAP users though can still confuse the meanings of Cancel and Error. > Remove Ack and Error msgTypes > ----------------------------- > > Key: EMERGENCY-33 > URL: https://issues.oasis-open.org/browse/EMERGENCY-33 > Project: OASIS Emergency Management TC > Issue Type: Bug > Components: CAP > Reporter: Steve Hakusa > > The proposal in this issue is to remove Ack and Error from the msgType enum. > Ack and Error were originally designed for use in 2-way communication, but the CAP-SC hasn't seen evidence of CAP being used in this way. Thus it may be conceptually simpler to remove the functionality from the next version. -- This message was sent by Atlassian JIRA (v6.2.2#6258)


  • 2.  Re: [emergency] [OASIS Issue Tracker] (EMERGENCY-33) Remove Ack and Error msgTypes

    Posted 11-22-2014 02:13
    Although I don't have a copy handy I seem to recall that the IPAWS profile uses Ack and Error. Although many, although not all, applications use TCP transport that provide a degree of reliability at a lower level, that's not guaranteed or required. In any event that still doesn't deal with the potential for bad XML or protocol/profile errors. I'm not aware of anyone having actually confused the Cancel, which comes from an alert source, with the Error, which is in a different section of the CAP alert and originates from an alert recipient. Error indicates a rejection of a message by a recipient, while Cancel indicates a retraction of a message by an originator. The two semantics are quite distinct... possibly it needs to be explained better but that's quite a way from a need to remove the option.