Original text:
want to always "Prohibit Cellular". The set of interface types is expected to change over time as new <del> access technologies become available. </del>  Interface types should not be treated as a proxy for properties of interfaces such as metered or unmetered network access.  If an

Reviewer comments:
from Kyle: Philipp Tiesel:
I'm not sure what Philipp's response means. Where is this registry, and why was it not useful?
Kyle Rose's review: URL
This will be system/implementation specific in general, I'd say.
Add a sentence to 5.2.10 to indicate that this is implementation specific
Mention that these should be documented? I've completed my review of draft-05, inline below. I will also submit a PR with minor changes that I recommend be addressed via cherry-picking agreed-upon hunks from the diff. 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. The notation "Sender -> Event" says nothing about who receives the event. Is it just assumed to be the application in the context of the particular event (e.g., a thread processing a particular connection)? 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: "URL for configuration of cryptographic identities and transport security parameters persistent across multiple Connections" "An application primarily interacts with this interface..." This seems awkward. An interface is the means by which an application interacts with the underlying transports. Transport Property Names The use of dashes in property names means they will necessarily look different in almost every widely-used language, in which dash is an operator. If we're not currently asking IANA to create a registry of property names or namespaces, should we provide a recommendation that such symbols not listed explcitly in this document be prefixed with some experimental identifier? 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. Also: why "exclusive of appendices"? Specifying Transport Properties There are a lot of choices being made about how users will want to prioritize transport protocol selection. How confident are we that, for instance, path selection should take priority over protocol selection? I think that's right, but I wonder if it might not make more sense to have two interfaces: one that provides a purely numeric priority ordering of preferences, and one (based on the existing 5-level preferences) that maps into it. "As preference typed selection properties..." I can't parse this. Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output of selected properties seems like a shortcut that will lead to some confusion. Use 0-RTT Session Establishment with an Idempotent Message I'll repeat the same statement I made at the mic a few years ago: idempotency != replay-safe. DELETE is idempotent, but not safe for replay because someone might have done a PUT or POST in the meantime. Interface Instance or Type These type symbols really deserve an actual registry, or at least the start of one. Otherwise, we are likely to end up with a mess. Provisioning Domain Instance or Type What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi. Connection Establishment Callbacks What constitutes trust verification prior to the handshake? Connection Groups "An ideal transport system" for whom? The capacity partitioning recommended here seems purely subjective. I'd just remove it. Sent It seems like an abstract API would be helpful for the reference to the Message to which a Sent event applies: this seems like something many, many applications would need to do. With callbacks, the application can always curry in a reference to the original message (that's what my event system from ~2001 did), so maybe that should be the recommendation and the message reference removed...? I don't have a strong feeling here other than that if something is included then its use should be more well-defined. SendError Is there a reason why a single messageContext object is used for both sends and receives? I probably missed the original discussion about this, but I'd like to understand the reasoning. Reliable Data Transfer (Message) The default isn't "true", it's whatever the underlying connection had, right? Singular Transmission Might be worth pointing out there's no guarantee here, either, considering resegmenting TCP middleboxes. Receiving Data A connection can be used to receive data if it is not configured as unidirectional transmit. Receive Events "A call to Receive will be paired with a single Receive Event" or possibly multiple ReceivedPartial Events? Also, can the draft be consistent about Receive vs. Received, et al.? 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. General comments There's a lot of UNIXisms here that should probably be excised in favor of a more abstract presentation. The most obvious is the use of -1 to mean something other than the integer -1. In Python, for instance, you might want to use None for this purpose. I would specify non-numeric values symbolically, and maybe indicate in the appendix that a UNIX C implementation might want to use -1 to represent such values. 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? Capacity Profile Very little of this section is about capacity. Traffic Profile? "High Throughput Data" might be better phrased as "Capacity-Seeking". Soft Errors Should the SoftError Event carry some information about e.g. the ICMP message received?

Revised text:
want to always "Prohibit Cellular". The set of interface types is expected to change over time as new  <ins> access technologies become available.  The taxonomy of interface types on a given Transport Services system is implementation- specific. </ins> Interface types should not be treated as a proxy for properties of interfaces such as metered or unmetered network access.  If an