BAM message response type about rfcs HOT 2 CLOSED

Thanks for your input! We are currently revising the the BAM-Error frame and plan changing it into a Close frame that can be sent by any party at any time. This Close frame would close the substream (including a reason), thus ending the communication in cases where a message (type) cannot be understood.
The general idea of BAM-Close (currently named BAM-Error) was introduced to have a unified way to reject message on the messaging layer, independent of underlying protocols (such as SWAP).

RFC-002 is already on the specific protocol (SWAP protocol) layer, thus the error handling is defined as part of the Response object that defines the decision in the header, which can be accepted or declined. If it was declined the Response object is defined by the DeclineBody, which can specify a decline reason, i.e.

{
  "type": "RESPONSE",
  "id": 0,
  "payload": {
    "headers": {
      "decision": "declined"
    },
    "body": { 
      "reason": "...",
      "details": "..."
    }
  }
}

It might seem over-engineered at first. Before we actually only had Request and Response - and the Response defined Error-Codes that would include errors on the messaging layer. However, the Response is the answer to a Request and is defined by the underlying protocols and should not leak up to the messaging layer.
Frames are made up of type and payload - if an incoming frame defines a type that is not understood there should be specific error handling for it (detached from the Response type that defines a response for frames of type Request), thus the Error frame was introduced.

from rfcs.

@birnbuazn you might like that: #117

from rfcs.