STREAM RFC: codify the conditions for a ConnectionAssetDetails frame being returned from a receiver.

[theotherian]

Information that inspired this issue:

• feat: expose asset details interledgerjs/ilp-protocol-stream#69
• Discussion on Enforce minimum exchange rates interledger-rs#273
• Discussion on Ensure StreamSender enforces Exchange Rates hyperledger-archives/quilt#261

Proposal:
STREAM RFC (il-rfc29) should codify the conditions for a ConnectionAssetDetails frame being returned from a receiver.

Question: What is the correct way to indicate a new Connection for a receiver?
Option1: Treat sequence of 1 as a new connection.
Option2: Whenever a ConnectionNewAddressFrame and a SendMoneyFrame are encountered.
Option3: Leave the RFC as is, which suggests only stateful receivers (see next question).

Question: should there be stateless receivers, or is this a protocol violation?

Question: What should a receiver reply with on a new connection?
Stateless:

• When receiver receives a ConnectionNewAddress and a StreamMoneyFrame frame from a sender, it should reply with a ConnectionAssetDetails frame.

Stateful:

• When receiver receives its first StreamMoneyFrame for a given connection, it should reply with a ConnectionAssetDetails frame.

[sappenin]

After discussing with @theotherian and @nhartner, we think the following are the correct path forward (also represented by PR #551):

Question: What is the correct way to indicate a new Connection for a receiver?

We want the RFC to be able to support stateless receivers and bi-directional streams (not at the same time, but in general -- and maybe only in the future). To this end, we shouldn't specify returning ConnectionAssetDetails on the first stream packet sequence number, because this may not be the point in time that one side or the other requires this information.

Instead, we should maintain the current Javascript Connector functionality (which is also what the Java Stream receiver does) and simply mandate that any endpoint receiving ConnectionNewAddress should respond with ConnectionAssetDetails. See the RFC PR (#551) for exact semantics here.

Question: should there be stateless receivers.

Yes, there are already stateless receivers in the wild that work just fine, so the RFC should not preclude them.

Question: What should a receiver reply with on a new connection?

See #551.

[adrianhopebailie]

@sappenin and @kincaidoneil interledgerjs/ilp-protocol-stream#112 was never resolved, does it have any bearing on this?

[kincaidoneil]

was never resolved, does it have any bearing on this?

Not really, I think it just underscores that it's important for the sender and recipient to exchange asset details, so we should support that for stateless receivers. AFAIK, David's PR should be fully compatible with the existing JS Stream implementation.