Code change:
will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to </del> <ins> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to </ins> Preferred properties, and then use Avoided properties as a <del> tiebreaker.  Selection Properties that select paths take preference over those that select protocols.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the protocol preference. </del> <ins> tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the

Related discussion:
text: I don't think a separate subsection would make this a better read - this fits fine as it stands, as an intro to the transport property specification IMO. Regarding normative language, that's a separate discussion. So, can we close this issue?
Agree that we don't need a separate subsection. I can try to tweak the beginning of this part a bit to explain why the rules exist as NAME suggested. Regarding normative language - we definitely have it in the API draft, right? So why not have the discussion on it here as well? if we're serious about deterministic outcomes, I guess the whole thing needs to be a MUST, right?
Sorry, true, that normative language debate was about the arch draft, and we definitely have it in the API draft. So yes, let's discuss it here. I also think a MUST would make sense.
So the order of filtering out require/prohibit is not important (outcome is the same) - making the order a MUST does not make sense. Also, first sorting by preference and then filtering has the same outcome as doing it the other way around. the only thing we need to say is that filtering MUST happen and sorting SHOULD happen.
ok - I have to admit I didn't think this through, I just agree that we want a deterministic outcome from this.
Why did we require a deterministic behavior in first place? Does this prevent TAPS implementations from running experiments like Apple did with TCP SACK and ECN? Does this prevent probabilistic path probing?
This was discussed in the TAPS BoF? ... I thought it was about developers being assured that X will happen if they choose Y and not finding the ground shifting as they use the interface.
Interim: Prefers and avoids allow the implementation to decide the ordering and weighting; require and prohibit are the only hard requirements. Applications should be able to cope with any possibility that isn't prohibited. Likely should add implementation text to say how preferences weight racing.
During the interim discussion, we found that was too strict and limiting, so we opted for another approach that moves the selection algorithm to the Implementation draft. I'm preparing another PR implementing these changes.
The text that ended up in the implementation draft is not fully consistent with the racing text, opening a new issue for this and closing this issue.
LGTM, merging this. thanks, Theresa!This reads good to me.