RFC 0003 Protocols - Added note about always ignoring unrecognized items in a message

[swcurran]

Also corrected the name of the problem-report message (vs. the report problem protocol name).

[swcurran]

@TimoGlastra -- this came up in the https://github.com/bcgov/aries-agent-test-harness when a test failed in ACA-Py based on a message from aries-framework-dotnet that had an unrecognized field that I think you mentioned was @id. I realize that although ACA-Py should have ignored that field, is the field there in place of an id field, or are both present? @id was used in the past (as I recall) but should no longer be used. Perhaps that is a transitional field?

[llorllale]

LGTM

[dhh1128]

Looks good to me, and this was discussed and approved on a community call. Merging.

[TimoGlastra]

@swcurran It was indeed the @id field. The value isn't set in the .NET framework, but due to how classes are parsed to JSON, unset values are included as null.

---

A recipient of a message from a supported major version of a protocol should ignore any unrecognized items in a received message

I'm curious if this also applies to the issue we had with the optional comment property in messages from .NET -> ACA-Py where ACA-Py only allowed the property to be of type string or for it to be left out, but .NET sends null.

[dhh1128]

@TimoGlastra That's an interesting side note: what does null mean with respect to optional fields. I think the answer is that null is not the same as <missing>. If others agree, we maybe ought to say that somewhere...

[swcurran]

Could someone else take a shot at that? I'm not the one to write that -- it gets a bit too far into JSON handling best practices for me.