Clarify better the role of client/server transaction ID headers and their relation to EPP

[pawel-kow]

Source: https://mailarchive.ietf.org/arch/msg/rpp/0qdZPjOWqXD-HMqkW3fHS4q0p_o
From Jasdip

Request Headers:
There are some headers that, IIUC, seem to connote EPP semantics, like “RPP-Cltrid” and “RPP-Svtrid”. Why not have them prefixed with “EPP-" to distinguish from the actual RPP headers like "RPP-Profile”? Also, is it safe to assume that they are optional for non-EPP use cases in RPP?

MW: If a header is only used for EPP (using RPP as proxy) then it must be optional , we can change the header name to make explicit that the header is for EPP only.

[PK] I will contradict what Maarten is telling. The headers happen to have the same name and happen to serve the same function as EPP-equivalents, but they are independent from EPP.

RPP-Cltrid is an audit trail and idempotency key same time. RPP-Svtrid is an audit trail which is critical in the provisioning system. The headers will work same way if there is no EPP server behind. Both are mandatory btw.

[JS] OK. For further clarity, good to include above rationale in the spec. Essentially, an implementer who has no prior EPP experience should be able to clearly follow this spec.

[mwullink]

after thinking more about this, we should minimise any relationship with EPP.
therefore it would be better not to have any identifiers that include "epp" in their name.

any relationship with EPP should be defined in separate RPP - EPP mapping documents.