Addressing some of Kyle Rose's comments

[mwelzl]

Here's the list of comments that this resolves, along with answers on how I did it:

2. Terminology and Notation

• "The method for
  dispatching and handling Events is an implementation detail, with the
  caveat that the interface for receiving Messages must require the
  application to invoke the Connection.Receive() Action once per
  Message to be received (see Section 8)."

This isn't true if ReceivedPartial events are triggered, right? Also, it's not really clear that any of this discussion belongs in a section titled "Terminology and Notation". This issue is alluded to later in the doc, and probably mostly belongs in the implementation doc.

MW: Agreed, removed this sentence.

3. Interface Design Principles

• What does "long-term caching of cryptographic identities" mean? The implication seems to be that credentials and transport security parameters can be configured once and used repeatedly. I'm not sure time interval ("long-term") is the right modifier here, and the word "caching" might be misunderstood as it means something subtly different in the realm of computer hardware and software than the dictionary definition implies. Maybe something like:

  "...and for configuration of cryptographic identities and transport security parameters persistent across multiple Connections"

MW: replaced as you suggest, because I believe that was the intended meaning anyway.

• "An application primarily interacts with this interface..." This seems awkward. An interface is the means by which an application interacts with the underlying transports.

MW: replaced "interface" with "API".

4.3. Scope of the Interface Definition

• "Implementations of this interface SHOULD implement each Selection
  Property, Connection Property, and Message Context Property
  specified in this document, exclusive of appendices. Each
  interface SHOULD be implemented even when this will always result
  in no operation, e.g. there is no action when the API specifies a
  Property that is not available in a transport protocol implemented
  on a specific platform."

This seems like it implies that a property that is unavailable should silently fail to be activated, which conflicts with the "Require" preference referenced later. There may be some way to reword this to be clear that it's referring to implementing all of the properties in the API so that compile-time or runtime errors don't spuriously occur when some symbol hasn't been defined.

MW: this wasn't about spuriously occurring compile-time or runtime errors but about implementing fall-backs because the API contract generally is only "best effort" except for things that will work over TCP. I inserted some more text here to clarify this better with examples.

Also: why "exclusive of appendices"?

MW: Good catch! That's a historical thing; I removed it. That appendix doesn't even exist anymore.

5.2. Specifying Transport Properties

• "As preference typed selection properties..." I can't parse this.

MW: it seems that this sentence has disappeared by now. There was another occurrence of "Preference-typed", which I changed into "of type 'Preference' ".

6.4. Connection Groups

• "An ideal transport system" for whom? The capacity partitioning recommended here seems purely subjective. I'd just remove it.

MW: I replaced "An ideal transport system implementation would" with "A transport system implementation should, if possible,". I believe that recommending a partitioning is necessary so that an application knows what to expect if things really work out. The particular described partitioning method is as good as any other, because, if it is implemented, an application can tune things as it wants anyway using the priority values. Without at least some sort of guidance on partitioning, the priorities become quite meaningless. With it, an application can at least say "this is how I'd like to divide the capacity, if at all possible".

7.4.9. Singular Transmission

• Might be worth pointing out there's no guarantee here, either, considering resegmenting TCP middleboxes.

MW: done (by adding ", if possible" to the first sentence).

9. Message Contexts

• "To get or set Message Properties, the optional scope parameter is
  left empty, for framing meta-data, the framer is passed." I can't parse this.

MW: It seems that this sentence has disappeared, auto-resolving this problem :)

11.1.3. Priority (Connection)

• I'm not sure what "relative inverse priority" means. Is P1 higher priority than P5, and therefore lower inverse priority than P5? Or the other way around?

MW: lower means higher priority. I added a bracket to clarify this.

11.2. Soft Errors

• Should the SoftError Event carry some information about e.g. the ICMP message received?

MW: yes. The text said "This event informs the application about the receipt of an ICMP error message related to the Connection" ... and I replaced "receipt" with "receipt and content".

[squarooticus]

Is it the case that all properties have such an escape clause if they can't be satisfied? The way this is worded, a developer might rely on a property that can't be satisfied on a particular platform or with a particular protocol, but which then fails silently. If it's made explicit that any requested property might fail silently, that issue is resolved, but the end result might be perverse. (E.g., on a hypothetical platform lacking support for TCP or QUIC, ordering may simply be unsatisfiable; is preserve-order then considered unimplemented, or implemented but ignored? What implication does that have for "require"?)

[mwelzl]

Everything is designed to be able to operate over TCP in the worst case - ensuring this, while not losing functionality, was the goal of the "minset" draft. So yes, all properties have an escape clause like this, or at least they should. Perverse results such as the one you describe shouldn't happen because one would fall back to ordered, not unordered. Picking out the ordering example: for message ordering, section 7.5.3, the text makes it clear that, if the application sets this to "true", it would only get ordered delivery. If it sets it to "false", according to the text, it may get its messages delivered out of order.

What implication does that have for "require": the idea is for "prefer" to work like we're discussing here, but for "require" to fail.

[squarooticus]

So, it's okay for this to fail? Or for the singular send to succeed, but for a middlebox to re-segment the data? The receiver therefore cannot rely on this property even if it knows a priori that the sender employed it.

Are we being clear enough that negotiated properties do not comprise a contract between sender and receiver?

[mwelzl]

Yes, it's ok for this to fail. Regarding the receiver and negotation: this is all one-sided! There isn't any negotiation here. A TAPS system can talk to a TAPS system on the other side, but it can also talk to a "normal" TCP peer, for instance.

[britram]

Merging this one to get new drafts out; let's continue the discussion at or after 107.