Help interpreting CA protocol

[Nicholas Devenish via Tech-talk <tech-talk at aps.anl.gov>]

Hi All,

I've been studying the CA protocol documentation (https://docs.epics-controls.org/en/latest/internal/ca_protocol.html), attempting to implement the
CA protocol as a learning exercise to become more familiar with EPICS. I've
found a few points of confusion that I'd appreciate help resolving - I think in
other places the source is referred to as the final word, but I've not yet gotten
good at finding things/navigating through the code base, (so tips on that/documented structure would also be welcomed).

Apologies for several large questions:

-----

CA_READ / CA_READ_NOTIFY Responses

The response is listed (for both responses) as parameter1 being "Server ID": https://docs.epics-controls.org/en/latest/internal/ca_protocol.html#id23, however in the "ECA Error/Status codes section", it explicitly mentions that return codes are sent in CA_PROTO_READ_NOTIFY, and the (invaluable) Wiresharks EPICS plugin at https://github.com/mdavidsaver/cashark does indeed list parameter1 as being the ECA return code.

Is this just a typo in the protocol documentation, and this field should indeed be the Status code instead of the Server ID? If not, presumably I send a CA_PROTO_ERROR instead of the expected response?

-----

CA_PROTO_SEARCH:

In the "comments" section `CA_PROTO_SEARCH` rather definitively says:

    > It is illegal to specify `DO_REPLY` flag whenever the message is sending as UDP datagram, regardless of whether broadcast or multicast is used."

However, immediately below it says:

    > Reply flag will be __generally__ DONT_REPLY when searching using broadcast

The choice of "generally" seems to imply that it can be set on a UDP search? In addition, the description for CA_PROTO_NOT_FOUND response says that it _is_ sent over UDP:

    > Sent in response to CA_PROTO_SEARCH, but only when its DO_REPLY flag was set. Sent over UDP.

Is this supposed to be sent if searching via UDP, and the notify flag is set, or ignored?
-----

Shorter questions:

- CA_VERSION lists several fields as "Must be 0". However, whilst sniffing the broadcast packets on our beamline network, I see quite a lot of searches where these fields have data in (and version is listed as 13). Are these malformed and should be ignored, or pragmatically replied to?
- The ECA Error-status-code-table at https://docs.epics-controls.org/en/latest/internal/ca_protocol.html#eca-error-status-codes lists `ECA_INTERNAL` as Severity "`CA_K_FATAL`". But this doesn't seem to be a valid severity (any more?). Should this read `CA_K_SEVERE`, or there is another (higher) value not documented by the severity code table?

Thanks,

Nick Devenish
(Diamond Light Source)