Closed Yanmei-Liu closed 1 month ago
We tried to clarify in the draft that these frames are only a recommendation and there is no requirement to follow this recommendation (there is also no way to enforce that, except closing/not opening the path). Therefore the final sending decision is left to the implementation. I don't think this is something we even could or should standardise as it will depend on the application and other local knowledge.
I agree with @mirjak that the current design is correct.
As stated in https://github.com/quicwg/multipath/issues/283#issuecomment-1793634282, I think what we have is a terminology issue and that is confusing us.
Although these Frames are preference(recommendation) not requirements, I still think we need more editorial guidance on this issue. When people write implementations, they would like to get deterministic results instead of vague response.
@Yanmei-Liu what kind of additional guidance do you think we should give?
Closing this issue. Please continue discussion in issue #283
When implementing -06 draft, we need to find out what to do when the signal from the peer(representing by the PATH_AVAILABLE/STANDBY frames) does not match the local API preference. There are several possibilities(mentioned by @Huitema):
Although the strategy is depending on the implementation, making the strategy clear about how to use PATH_AVAILABLE/STANDBY Frames is quite important in the draft.
So we track the issue here and hope to hear more voice from different people.