Summary
The CSA NHP standard Appendix 2 defines logical fields for NHP message bodies such as KNK, ACK, AOP, ART, AOL, AAK, ACC, LOG, LAK, and ARD.
Current OpenNHP main uses implementation-specific JSON payloads and field names that do not obviously map 1:1 to Appendix 2. Examples:
nhp/common/nhpmsg.go: AgentKnockMsg uses headerType, usrId, devId, orgId, aspId, resId, results, usrData.
nhp/common/nhpmsg.go: ServerKnockAckMsg uses resHost, opnTime, aspToken, agentAddr, acTokens, preActions, redirectUrl.
nhp/common/nhpmsg.go: ServerACOpsMsg uses srcAddrs and dstAddrs arrays rather than the standard's singular source/destination IP/port fields.
NHP_LOG, NHP_LAK, and NHP_ARD payloads are not present in the current core message definitions.
Why This Matters
Even if message type numbers match, payload-level interoperability with a CSA-standard peer may fail unless the mapping is explicit. Integrators need to know which fields are compliant aliases, which are OpenNHP extensions, and which standard-required fields are missing.
Suggested Acceptance Criteria
- Build a message-by-message compliance matrix mapping CSA Appendix 2 fields to current OpenNHP JSON fields.
- Mark each difference as compliant alias, OpenNHP extension, missing standard field, or incompatible drift.
- Add JSON schema or golden-vector tests for standard message bodies.
- Implement missing required fields or compatibility adapters where strict standard compliance is required.
- Document any intentional OpenNHP extensions and version/feature negotiation behavior.
Summary
The CSA NHP standard Appendix 2 defines logical fields for NHP message bodies such as KNK, ACK, AOP, ART, AOL, AAK, ACC, LOG, LAK, and ARD.
Current OpenNHP
mainuses implementation-specific JSON payloads and field names that do not obviously map 1:1 to Appendix 2. Examples:nhp/common/nhpmsg.go:AgentKnockMsgusesheaderType,usrId,devId,orgId,aspId,resId,results,usrData.nhp/common/nhpmsg.go:ServerKnockAckMsgusesresHost,opnTime,aspToken,agentAddr,acTokens,preActions,redirectUrl.nhp/common/nhpmsg.go:ServerACOpsMsgusessrcAddrsanddstAddrsarrays rather than the standard's singular source/destination IP/port fields.NHP_LOG,NHP_LAK, andNHP_ARDpayloads are not present in the current core message definitions.Why This Matters
Even if message type numbers match, payload-level interoperability with a CSA-standard peer may fail unless the mapping is explicit. Integrators need to know which fields are compliant aliases, which are OpenNHP extensions, and which standard-required fields are missing.
Suggested Acceptance Criteria