Then in all of the message descriptions (qry, rpy, etc...) we have the RFC compliant mandate that All are REQUIRED. No other top-level fields are allowed (MUST NOT appear).
This leads to contextual ambiguity about the ri field and if it is or isn't allowed to be in those messages.
There's also a side issue of why the ri field can't be assigned to the sender. Being able to exchange messages with oneself seems like a good testing tool for operators and doesn't seem to open any security holes I can think of. Maybe more detail on this would be helpful as well.
Not a typo see #200 ~In section https://trustoverip.github.io/tswg-keri-specification/#controller-aid-field we have (with typo "i" for "ri" but that can be easily fixed):~
~
A Receiver AID, i field MAY appear in other places in messages. In those cases, its meaning SHOULD be determined by the context of its appearance.
~Then an explanation of the field in https://trustoverip.github.io/tswg-keri-specification/#receiver-aid-field
Then in all of the message descriptions (qry, rpy, etc...) we have the RFC compliant mandate that
All are REQUIRED. No other top-level fields are allowed (MUST NOT appear).
This leads to contextual ambiguity about the
ri
field and if it is or isn't allowed to be in those messages.There's also a side issue of why the
ri
field can't be assigned to the sender. Being able to exchange messages with oneself seems like a good testing tool for operators and doesn't seem to open any security holes I can think of. Maybe more detail on this would be helpful as well.