Add clarification to thread RFC about handling an empty thread decorator

[swcurran]

Signed-off-by: Stephen Curran [email protected]

See issue #875 in Aries VCX. This PR clarifies that while it is not recommended, an Aries agent MAY put an empty ~thread: {} item in the first message of a protocol instance, and a recipient Aries agent MUST be able to handle that.

[usingtechnology]

That should help clear up the ambiguity.
The code in aries-cloudagent-python is very defensive and assumes ~thread may not exist and ~thread{} may exist without a thid. All applications should be coded with the same defensiveness.

[usingtechnology]

LGTM.

[gmulhearn-anonyome]

LGTM. But curious; why go this route rather than a route of "~thread MUST have a thid"?

[swcurran]

My thought is that making the thid required is a change in the protocol (and hence a minor version change), and simply being defensive in the implementation is sufficient. And, even if we make the change now, some implementations may not do it, and so it is best to be defensive anyway.

[gmulhearn-anonyome]

thanks, sounds good

[usingtechnology]

Not that ACA-Py's implementation should dictate the RFC, but whoever implemented it in ACA-Py understood it as expecting to encounter a thread without a thid. And unfortunately, in ACA-Py the thread logic is not 100% isolated. Ensuring that all threads had a thid with a value would be a fairly significant exercise, certainly at the regression testing level.

[TimoGlastra]

I think it's valid to have a pthid, without a thid, so making this required would also be problematic in such cases

[TimoGlastra]

AFJ has same behaviour, that is allows an empty object

[swcurran]

Discussed on the Aries Working Group call on 2023.06.28 and there was agreement to merge.