Empty messages: Imprecise specification and differing interpretations

[nirajankeybridge]

The specification does not indicate expected implementation logic for invalid (i.e. empty) relinquishment request. We interpret an empty request to indicate no relinquishment and should therefore not be sent. If sent an empty (NULL) message should return an error code.

Accepting empty (i..e null) messages will mask potential errors in the Domain Proxy or CBSD and is not good practice.

Example message in ITS study guide:

{“relinquishmentRequest”: [] }

ITS configuration expected Response:

{“relinquishmentResponse”: [] }

Do certified CBSDs and DomainProxys expect or accept/ignore these responses? If not how do they identify relinquishment errors? We believe this is an invalid transaction request and should return an error as no relinquishment was offered.

Feedback received
[Kate] WinnForum already agreed that configs with empty requests are invalid (and we would have unanimously changed the WG4 spec to match the WG3 spec, but we feared it would cause further delays). I passed on this information to ITS during one of the test dev calls, and I believe Masoud was supposed to do the same via email (though I never saw such an email).

[kate-harrison]

This is not an issue with the WinnForum test code, but rather with the ITS study guide.