Treatment of optional transport properties

[MaxF12]

What is the expected treatment of protocols that provide certain properties but which are not a mandatory part of the protocol, e.g. multistreaming in SCTP. If the application prohibits multistreaming, will SCTP be discarded during the candidate selection process? Will the API simply set the max in- and outbound streams to 1 during initialization of the SCTP association? What happens in cases where the API is not able to reliably turn individual properties on and off?

[mwelzl]

My immediate response would be "that's up to you as an implementer". I actually believe we should not specify expectations like this - perhaps just discuss a possible decision (as an example) in the implementation draft?

[philsbln]

Text proposal for Implementation:

If an application specifies to "prohibit" some feature, the implementation SHOULD disable this feature if possible and SHOULD emit an appropriate error signal if the feature is used by either the local or the remote endpoint. Whether the existence of an (optional) feature excludes protocol stacks form being selected should be weighed by implementors on an individual basis.

[mwelzl]

Why translate "prohibit" into SHOULD? Clearly this is a MUST? and this text proposal is confusing IMO because "prohibit" refers to the feature as exposed to the application, so saying "disable this feature if possible" seems really strange to me.

[gorryfair]

I really think we should not use the RFC2119 keywords in this way in the implementation draft. I don't even say we ought to tell implementors how to to violate a MUST, better we leave the API to speak to this, and (perhaps - if we need) identify considerations in the implementation, but don't start redefining the spec. I suggest we say noting on this point.

[mwelzl]

Oh yes, RFC 2119 language is even altogether inappropriate in this draft. I fully agree.

[philsbln]

@mwelzl and @gorryfair - you both convinced me… so I'd like to change my "SHOULD" into "must" and ask for feedback whether we want to have this note in Implementation or rather not say anything.

[gorryfair]

I still prefer to say less: In answer to the original question, I'd suggest:

If an application prohibits multistreaming, then the underlying transport must not utilise this. A TAPS system could still select a transport that permits this feature, providing that the multistreaming function is not used (e.g. an SCTP association, limited to one outbound stream). However, in this example, if there were no additional reason to choose SCTP, then the system could be setup to prefer to use TCP to satisfy this request.

[MaxF12]

Thanks for the comments, it will remain implementation specific.