Question:
On the mailing list, NAME and NAME pointed out some risks arising from the default virtual host behavior of some web servers. This PR integrates the changes they suggest, namely (1) removing the "tls" option from the challenge, and (2) adding iterations to the challenge. This PR is based on top of and .
Sorry, feel free to tell me to go away, but reading the backing decision to drop HTTPS for SimpleHTTP doesn't make sense to me. If I understand everything correctly, you control the originator of the HTTPS requests and the requests are always sent to domains. So why can't you just enforce to always send the Host header and this wouldn't be an issue?
From : behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). As far as I know Apache does the exact same thing for nonencrypted HTTP hosts (this is also acknowledged by a later mail in the thread), so the reasoning is a little weird. I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS?
The section on the "" registry says that "Fields marked as "client configurable" may be included in a new-account request". This seems like a copy-paste-o, and perhaps should say that such fields may be included in a new-order request.
Good catch. I opened URL to fix. Thanks! Apache (and I gather nginx too) have the subtle and non-intuitive behaviour that if a default TLS/HTTPS virtual host is not configured explicitly, one will be selected based on the ordering of vhosts in the webserver configuration (in practice, this often amounts to alphabetical ordering of files in a configuration directory). URL URL This creates a vulnerability for SimpleHTTP and DVSNI in any multiple-tenant virtual hosting environment that failed to explicitly select a default vhost [1]. The vulnerability allows one tenant (typically one with the alphabetically lowest domain name -- a situation that may be easy for an attacker to arrange) to obtain certificates for other tenants. The exact conditions for the vulerability vary: SimpleHTTP is vulnerable if no default vhost is set explicitly, the server accepts the "tls": true parameter as currently specified, and the domains served over TLS/HTTPS are a strict subset of those served over HTTP. DVSNI is vulnerable if no default vhost is set explicitly, and the hosting environment provides a way for tenants to upload arbitrary certificates to be served on their vhost. James Kasten and Alex Halderman have done great work proposing a fix for DVSNI: URL That fix also has some significant performance benefits on systems with many virtual hosts, and the resulting challenge type should perhaps be called DVSNI2. The simplest fix for SimpleHTTP is to remove the "tls" option from the client's SimpleHTTP response, and require that the challenge be completed on port 80. URL Alternatively, the protocol could allow the server to specify which ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on port 443 SHOULD be avoided unless the CA can confirm that the server has an explicitly configured default vhost. The above diffs are currently against Let's Encrypt's version of the ACME spec, we'll be happy to rebase them against the IETF version upon request. [1] though I haven't confirmed it, it's possible that sites that attempted to set a default vhost are vulernable if they followed advice like this when doing so: URL ; an attacker need only sign up with a lexicographically lower name on that hosting platform to obtain control of the default. Peter Eckersley EMAIL Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993

client's control of the domain by verifying that the TLS server was configured appropriately. <del> Compute the Z-value from the authorized key object in the same way as the client. </del> <ins> Choose a subset of the N DVSNI iterations to check, according to local policy. For each iteration, compute the Zi-value from the authorized keys object in the same way as the client. </ins> <del> Open a TLS connection to the domain name being validated on port 443, presenting the value "<Z[0:32]>.<Z[32:64]>.acme.invalid" in the SNI field (where the comparison is case-insensitive). </del> <ins> Open a TLS connection to the domain name being validated on the requested port, presenting the value "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" in the SNI field (where the comparison is case-insensitive). </ins> Verify that the certificate contains a subjectAltName extension <del> with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid". </del> <ins> with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid", and that no other dNSName entries of the form "*.acme.invalid" are present in the subjectAltName extension. It is RECOMMENDED that the ACME server verify a random subset of the N iterations with an appropriate sized to ensure that an attacker who can provision certs for a default virtual host, but not for arbitrary simultaneous virtual hosts, cannot pass the challenge.  For instance, testing a subset of 5 of N=25 domains ensures that such an attacker has only a one in 25/5 chance of success if they post certs Zn in random succession.  (This probability is enforced by the requirement that each certificate have only one Zi value.) </ins> It is RECOMMENDED that the ACME server validation TLS connections from multiple vantage points to reduce the risk of DNS hijacking


Question:
Included in the text. Maybe will include further text for
In 5.5.1: This kind of suggests that an Agent may also not know the serial number. But in creating the agent-signed-data, this number is required later on. Could we clarify perhaps the Agent MUST know the serial-number; e.g. in one of these ways: configured (as in quoted text above) discovered (in "standard" way using mDNS / DNS-SD first part of service instance name) discovered (in vendor-specific way e.g. RF beacons) other (in vendor-specific way, e.g. scan QR code of packaging) - maybe that's the same as category 1 from the Agent point of view.
Additional Note: figure 4 doesn't show the part where the Agent discovers the serial number of the Pledge. This was adding to the confusion. Maybe figure 4 can stay as is; this is just to clarify that at the start of Fig 4 the Agent MUST know the serial-number. So some small link is missing to get the complete picture.
I reopened as the initial point if the registrar-agent MUST know the serial number is not solved by the QR code reference. As the registrar-agent needs to know, which pledges he is bootstrapping, he needs the list of serial numbers in advance to be able to construct the agent signed data. Text proposed will be included into the pre-conditions described in section 5.5.1, In addition, the registrar-agent MUST know the product-serial-number(s) of the pledge(s) to be bootstrapped. The registrar-agent MAY be provided with the product-serial-number in different ways: configured, e.g., as a list of pledges to be bootstrapped via QR code scanning discovered by using standard approaches like mDNS as described in 5.4.2. discovered by using a vendor specific approach, e.g., RF beacons
Ok

This is necessary to allow the discovery of pledges by the registrar- agent using mDNS.  The list may be provided by administrative means or the registrar agent may get the information via an interaction <del> with the pledge, like scanning of product-serial-number information using a QR code or similar. </del> <ins> with the pledge.  For instance, RFC9238 describes scanning of a QR code, the product-serial-number would be initialized from the 12N B005 Product Serial Number. </ins> According to RFC8995 section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the


Question:
It seems blindingly obvious to me that an implementation would need to take care of this... and this note of caution seems quite appropriate (if unnecessary... but surely it doesn't hurt).
Dynamic framer add and passthrough (last two paragraphs of section 6.1) assume synchronous operation; what happens to bytes in the send/receive buffers when the framer stack changes? There either needs to be an explicit mutex here (allowing the framer/implementation to lock the buffers at the exact point the framer change happens, not allowing any bytes to be processed while the dynamic framer decision is made), or some way to annotate in a buffer the replay point after which a dynamic reframing is necessary. Are we going to leave this up to implementors to figure out, or should we point out that here be dragons?
We should clarify that these operations within the data path of the stack should be synchronized.

the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The Transport Services implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior.  For example, some of the actions defined below (such as PrependFramer and StartPassthrough) modify how data flows in a protocol stack, and require synchronization with sending and parsing data in the Message Framer. </ins> When a Connection establishment attempt begins, an event can be delivered to notify the framer implementation that a new Connection is being created.  Similarly, a stop event can be delivered when a


Question:
SORRY I made a PR on your PR, when I meant to leave a review comment, see 1024. .... Silly to make a PR on a PR - I added a review comment instead...
In section 4.1.4 in the impl draft, we have: "The order of operations for branching, where lower numbers are acted upon first, should be: Alternate Paths Protocol Options Derived Endpoints" However, I would say there is not really a strict ordering required. The text actually indicates that selection of the protocol is rather independent while there is usually a dependency between the interface and derived endpoint. I think this is related to my other issue about the use of the term path, because a path consists of both the local and remote endpoint and therefore there is of course a dependency. So in summary I'm not sure how useful I find this whole section as currently written...
We should conclude if anything more is needed here besides cleaning up the terminology, where Alternate Paths is not a good term - see .
Any implementation should have a consistent order of operations. This is a recommended example. Reference the arch text that says it needs to work the same way each time.
Reference ICE/HE

4.1.2. <del> Branch types must occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations must be careful to branch in an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. The order of operations for branching should be: Alternate Paths </del> <ins> Branch types ought to occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings.  In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations need to be careful to branch in a consistent order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. This document recommends the following order of operations for branching: Network Paths </ins> Protocol Options


Question:
NAME wrote: "Why is the text talking about "many properties" that can no longer be changed, instead of relying on the earlier, nice and clear distinction between Selection and Connection Properties?". => In line with the suggestion from NAME this is now changed, it says Selection Properties. NAME wrote: "Where earlier, Selection Properties were said to remain readable, now they are only queryable?". => In line with NAME answer, this PR replaces "query" with "read" in this text. NAME wrote: "Are "applied" Selection Properties still Selection Properties? Shouldn't they better be referred to using a different term?" and here, NAME suggested: "In the , we define Protocol Stack as a Transport Services implementation concept, and we talk about a certain protocol stacks providing certain features (see . Perhaps we could rephrase this part of the API draft to use that terminology, e.g., the application can query the actually used protocol stack and then know which Transport Features it supports." => I don't know how to apply this change, and it generally sounds a bit complicated to me. I think that Selection Properties should keep their name. Regarding the confusing text with the example, I removed this and I think it makes things clearer. Regarding the return type, I think I now finally understood the bigger problem. Returning a Boolean instead of a Preference should make sense and should be easy to implement (as also described in this PR). The problem is that not all Selection Properties are of type Preference. E.g., is an enumeration, representing , or . What sense does it make if this becomes only or ? Similarly, and are of type "Collection of (Preference, Enumeration)", and indeed it would make sense to expect a Collection of booleans, not a singular boolean. This PR now explicitly says that, upon reading, the Preference type of a Selection Property (not the whole Selection Property!) changes into Boolean.
MANY thanks for the proposed fix (which I committed)! I hadn't really understood the problem just from reading the issue discussion.
As , here follows a bit of feedback on the different Property types in the Interface draft, from the perspective of an academic developer who is currently attempting to follow the draft spec as closely as possible while trying to implement a path-aware transport system in a In , it says: At this point, the reader of the document could be expected to conclude the following: Selection Properties are a set of preferences for protocol/path selection that (obviously) can no longer be meaningfully changed once a connection has been established. Connection Properties are a set of "run-time preferences" for connections which could still be adjusted when a connection is already established, but should ideally already be known during protocol/path selection The text goes on to state: With this wording, the reader can now reasonably conclude that the original Selection Properties that have resulted in a given Connection should remain available during the lifetime of that Connection, perhaps in form of a copy of the original data structure. So far so straight forward. In however, this conclusion is called into question. After the text has gone on to introduce the 5 different Preference Levels, it states At this point, the reader becomes confused. Why is the text talking about "many properties" that can no longer be changed, instead of relying on the earlier, nice and clear distinction between Selection and Connection Properties? Where earlier, Selection Properties were said to remain readable, now they are only queryable? The type of a Selection Property that has been "applied" mutates from a Preference Level to become a Boolean? Are "applied" Selection Properties still Selection Properties? Shouldn't they better be referred to using a different term? So the original Selection Preferences that resulted in the current Connection are not available after all? Only the (Boolean) Properties of the chosen Protocol can be "queried"? But wait, the text goes on: This is a complicated way of saying that the values only reflect the actual Properties of the chosen Connection and (in direct contradiction to the previous paragraph) do not actually indicate whether a Selection Property has also been "applied" or not. (A Boolean only carries exactly one bit of information after all.) In other words, the Protocol Properties can be queried. The usefulness of this is probably limited however. If we already know that our Connection is using, e.g., TCP, we don't have to issue any "queries" to know that the Connection offers reliable transport, is subject to congestion control and preserves packet ordering. (This is indeed how I have chosen to implement this. The chosen Protocol can be queried for the Properties it inherently has. In the Preconnection phase, the Selection Preferences are matched against these and any / conflict results in that Protocol being dropped from consideration.) Hoping not to be unreasonable (or somehow block-headed), I have the following suggestions Either introduce a new term for Properties that have been "applied", or Use the term "Preferences" (e.g., "Selection Preferences", "Connection Preferences") to refer to a collection of adjustable "Settings" and the term "Properties" to refer to measured or queried values that are actual Properties of underlying Connections and Protocols Go into a bit more detail about what the draft really means when talking about "querying" Properties (versus setting them), maybe even in terms of exemplary interactions with Property data structures. (After all, the draft elsewhere goes into considerable detail with it's exemplary Event-based system) Think about whether it in general would clear things up when the explicit notion of Protocol Properties as a (static) counterpoint to (adjustable) Selection Properties is introduced
(Replying as an individual and co-author) Thanks for raising this issue! Yes, this matches my understanding is well. If the later text confuses this issue for the reader, then perhaps we'll need to tweak it. I'd say that Selection Properties can no longer be changed, Connection Properties still can be changed (though maybe changing a Connection Property later would not have any effect, e.g., if Capacity Profile changes but was only taken into account when selecting a path). Perhaps the text should reflect that. For me, these are synonyms, whereby a "query" is what the application has to do in order to read the properties. Perhaps the "queried" should become "read" to avoid confusion. That is indeed how I think of it on a conceptual level, but I understand how this might confuse implementers, especially if they can't just change a data type of a property. In the , we define Protocol Stack as a Transport Services implementation concept, and we talk about a certain protocol stacks providing certain features (see . Perhaps we could rephrase this part of the API draft to use that terminology, e.g., the application can query the actually used protocol stack and then know which Transport Features it supports. I would strongly prefer using our existing terminology to introducing yet another term. Good question. I vaguely remember discussing this, and I think folks felt like querying the Selection Properties that the application had set was not very useful at that stage. The other text you quoted indeed sounds a bit complicated and maybe it can be reworded to be clearer. Curious to hear what my co-authors and/or other TAPS participants think!
I completely second what NAME wrote. With regards to querying the Transport Features selected vs. getting the preferences provided earlier, I remember we had lengthy discussions and somewhat converged to the current state. Primary arguments ware Multiple read/query variants are confusing Original Preferences are not really useful - if you really want to read them later, keep the Preferences Object Constrained implementations don't want to be forced to store them. NAME based on these arguments, what option would you prefer a) different get/query operations of selection properties after the connection has been set up b) the current way of "mutating" preferences with clearer description in the text
Just to add: having finally gotten around to carefully reading this, I also completely agree with everything NAME wrote. This is exactly how I would have answered, and her suggestions are exactly what I think should be done to address these comments. I also agree with NAME that these were the arguments regarding querying the querying issue, and I agree with the arguments as well. The quoted text containing the example is a great catch! Such a terribly convoluted paragraph. I have a nagging feeling that this was my fault! :-(
PR tries to solve this; the PR itself contains a full explanation of my rationale for the changes. Please take a look!
Great, this looks good to me now. I think now it is simple enough that we don't need an example anymore.Looks good, one clarification suggestedWorks for me (with NAME changes). I would propose a slight rewording -> and add a hint that this exposing can also be implemented differently.

more. connection-props provides a list of Connection Properties, while <del> Selection Properties are listed in the subsections below.  Many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can still be queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If the preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </del> <ins> Selection Properties are listed in the subsections below.  Selection Properties are only considered during establishment, and can not be changed after a Connection is established.  After a Connection is established, Selection Properties can only be read to check the properties used by the Connection.  Upon reading, the Preference type of a Selection Property changes into Boolean, where "true" means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and "false" means that the Protocol Stack does not support the feature or use the path. Implementations of Transport Services systems may alternatively use the two Preference values "Require" and "Prohibit" to represent "true" and "false", respectively. </ins> An implementation of the Transport Services API must provide sensible defaults for Selection Properties.  The default values for each


Question:
Appendix B.1 lists two properties as "under discussion": Bounds on Send or Receive Rate: (PR 1036 fixes the name): this is no longer under discussion, these properties exist. Cost Preferences: this is no longer under discussion, I suppose?? We don't have this in the interface draft. So I have the impression that this should no longer be an appendix, the text on Cost Preferences should be removed, and the text on Bounds on Send and Receive Rate should be moved elsewhere, and not be mentioned as "under discussion".
LGMT

highest available capacity, based on the observed maximum throughput. <ins> As another example, branch sorting can also be influenced by bounds on the Send or Receive rate (Selection Properties "minSendRate" / "minRecvRate" / "maxSendRate" / "maxRecvRate"): if the application indicates a bound on the expected Send or Receive bitrate, an implementation may prefer a path that can likely provide the desired bandwidth, based on cached maximum throughput, see performance- caches.  The application may know the Send or Receive Bitrate from metadata in adaptive HTTP streaming, such as MPEG-DASH. </ins> Implementations process the Properties (Section 6.2 of I-D.ietf-taps- interface) in the following order: Prohibit, Require, Prefer, Avoid. If Selection Properties contain any prohibited properties, the


Question:
Capitalization seems to be a problem for us. We need to make things uniform. At first, I reacted to seeing "connection" as parameters in this PR, because we use the term "Connection" to refer to a TAPS-provided connection (as opposed to a connection of the underlying system), and so, de-capitalizing the term here may look better, but it is also somewhat imprecise. This said, we do the same with other capitalized terms too, here and in the API draft - e.g., "messageContext". Should we generally agree to begin terms with a lowercase letter when they are used as parameters in code examples? I think we have this in most places, though at least the API draft has several counterexamples... e.g., the server example code: Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) (..) Listener -> ConnectionReceived
From discussion on
This was a mistake. As I wanted to do this now, I noticed that all occurrences of capitalized terms as parameters are objects that are defined and used elsewhere in the code examples. For example: Preconnection := NewPreconnection(RemoteSpecifier, TransportProperties, SecurityParameters) refers to RemoteSpecifier etc., being objects that are initialized some lines above. Making them appear in lower case everywhere would be awkward, this is then a much more drastic change to our pseudocode. As a result, I think it's fine to leave things as they are, and I suggest to close this issue with no action.
Framers: What is the difference between the Final message property and the separate IsEndOfMessage event argument?
Also there, the term MessageContext could use a definition
and searching "isEndOfMessage" tells me that there is no text describing this parameter. Regarding the question, the difference should be clear: seems self-explanatory, whereas indicates that the Message carrying it is the last one of the Connection. So, this is End of the Message vs. End of the Connection.
Sounds like this needs a reference to the API doc, and change IsEndOfMessage to endOfMessage to match the API.
Probably fix with
I think this looks ok (and thanks for doing this!), but see also my comment about making things uniform wrt. capitalization: if we merge this PR, we should also do one that does the same with the API draft.Thanks LGTM! Although I noticed another nit that can perhaps be fixed in the same PR even if not directly related to the parameter names. Regarding the capitalization I think we can merge this PR and then have a separate issue for the capitalization as we will need to fix this either way.

implementation to communicate control data to the Remote Endpoint that can be used to parse Messages. <ins> Once the framer implementation has completed its setup or handshake, it can indicate to the application that it is ready to handling data with this call. </ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has <del> finished with this. </del> <ins> finished with this call. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error.


Question:
Capitalization seems to be a problem for us. We need to make things uniform. At first, I reacted to seeing "connection" as parameters in this PR, because we use the term "Connection" to refer to a TAPS-provided connection (as opposed to a connection of the underlying system), and so, de-capitalizing the term here may look better, but it is also somewhat imprecise. This said, we do the same with other capitalized terms too, here and in the API draft - e.g., "messageContext". Should we generally agree to begin terms with a lowercase letter when they are used as parameters in code examples? I think we have this in most places, though at least the API draft has several counterexamples... e.g., the server example code: Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) (..) Listener -> ConnectionReceived
From discussion on
This was a mistake. As I wanted to do this now, I noticed that all occurrences of capitalized terms as parameters are objects that are defined and used elsewhere in the code examples. For example: Preconnection := NewPreconnection(RemoteSpecifier, TransportProperties, SecurityParameters) refers to RemoteSpecifier etc., being objects that are initialized some lines above. Making them appear in lower case everywhere would be awkward, this is then a much more drastic change to our pseudocode. As a result, I think it's fine to leave things as they are, and I suggest to close this issue with no action.
Framers: What is the difference between the Final message property and the separate IsEndOfMessage event argument?
Also there, the term MessageContext could use a definition
and searching "isEndOfMessage" tells me that there is no text describing this parameter. Regarding the question, the difference should be clear: seems self-explanatory, whereas indicates that the Message carrying it is the last one of the Connection. So, this is End of the Message vs. End of the Connection.
Sounds like this needs a reference to the API doc, and change IsEndOfMessage to endOfMessage to match the API.
Probably fix with
I think this looks ok (and thanks for doing this!), but see also my comment about making things uniform wrt. capitalization: if we merge this PR, we should also do one that does the same with the API draft.Thanks LGTM! Although I noticed another nit that can perhaps be fixed in the same PR even if not directly related to the parameter names. Regarding the capitalization I think we can merge this PR and then have a separate issue for the capitalization as we will need to fix this either way.

6.2. Message Framers generate an event whenever a Connection sends a new <del> Message. </del> <ins> Message.  The parameters to the event align with the Send call in the API (Section 9.2 of I-D.ietf-taps-interface). </ins> Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting


Question:
Capitalization seems to be a problem for us. We need to make things uniform. At first, I reacted to seeing "connection" as parameters in this PR, because we use the term "Connection" to refer to a TAPS-provided connection (as opposed to a connection of the underlying system), and so, de-capitalizing the term here may look better, but it is also somewhat imprecise. This said, we do the same with other capitalized terms too, here and in the API draft - e.g., "messageContext". Should we generally agree to begin terms with a lowercase letter when they are used as parameters in code examples? I think we have this in most places, though at least the API draft has several counterexamples... e.g., the server example code: Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) (..) Listener -> ConnectionReceived
From discussion on
This was a mistake. As I wanted to do this now, I noticed that all occurrences of capitalized terms as parameters are objects that are defined and used elsewhere in the code examples. For example: Preconnection := NewPreconnection(RemoteSpecifier, TransportProperties, SecurityParameters) refers to RemoteSpecifier etc., being objects that are initialized some lines above. Making them appear in lower case everywhere would be awkward, this is then a much more drastic change to our pseudocode. As a result, I think it's fine to leave things as they are, and I suggest to close this issue with no action.
Framers: What is the difference between the Final message property and the separate IsEndOfMessage event argument?
Also there, the term MessageContext could use a definition
and searching "isEndOfMessage" tells me that there is no text describing this parameter. Regarding the question, the difference should be clear: seems self-explanatory, whereas indicates that the Message carrying it is the last one of the Connection. So, this is End of the Message vs. End of the Connection.
Sounds like this needs a reference to the API doc, and change IsEndOfMessage to endOfMessage to match the API.
Probably fix with
I think this looks ok (and thanks for doing this!), but see also my comment about making things uniform wrt. capitalization: if we merge this PR, we should also do one that does the same with the API draft.Thanks LGTM! Although I noticed another nit that can perhaps be fixed in the same PR even if not directly related to the parameter names. Regarding the capitalization I think we can merge this PR and then have a separate issue for the capitalization as we will need to fix this either way.

In order to parse a received flow of data into Messages, the Message Framer notifies the framer implementation whenever new data is <del> available to parse. </del> <ins> available to parse.  The parameters to the the events and calls for receiving data with a framer align with the Receive call in the API (Section 9.3 of I-D.ietf-taps-interface). </ins> Upon receiving this event, the framer implementation can inspect the inbound data.  The data is parsed from a particular cursor


Question:
Takes care of item 5 and .
See discussion on
Provide a complete template that covers all functions/properties from the API. Indicate how the template should be used (e.g. leave out the parts that are not relevant for a particular protocol or include all fields and mark fields that are not relevant as such.
I'm wondering if this is really something that's in scope that we should cover. We do have the message properties section that explains how to implement various properties, but I think adding each property to every protocol mapping will be a huge amount of text that will be difficult to get exactly right.
I agree, we have added additional properties since we opened this issue to check the mapping and make sure we have a complete coverage. We should still be consistent in how we treat things though, and perhaps add a sentence that we do not describe all the properties for instance. I have made a pass through to check the mapping from the API to impl. draft for all the protocol mappings as a basis for making things consistent. Here is the summary. We cover the same actions and events for all the protocols with the exceptions that UDP Multicast does not cover the ConnectionError event and SCTP covers the Priority connection property. And MPTCP and UDP-lite are special as they refer back to the base protocols. There is one terminology inconsistency where the impl. draft refers to InitiateError and this has been generalized to EstablishmentError in the API Unless I missed something, there are only two actions that can be made on a connection that are not covered, addRemote and removeRemote. This is probably fine as they do not mean much for most of the protocols (or we could add them to be complete). We should perhaps mention how they relate to MPTCP though if we leave them out. We also do not cover the Preconnection.Rendezvous action. Again this may be fine as it is a bit special (or we can mention it for consistency.) For the events, we cover a subset with main focus on the connection related events. The Closed Event and some events related to connection setup are missing. As we cover ConnectionError we should perhaps cover the Closed event as well? We do not cover any of the Send or Receive events which seems fine. In relation to Connection and Message properties, we do not cover any of them except for the Connection priority covered for SCTP and we talk about some properties in connection to UDP-lite and MPTCP. SCTP also has support for partial reliability and unordered messages so not sure why the priority part was singled out and added. NAME any particular reasoning behind this part? Possibly we should remove the priority part for SCTP or discuss it in running text in a similar fashion as for UDP-lite and MPTCP We may want to update the UDP-lite description to also say something about what properties it supports over UDP. The current description sounds like it is a subset. Once we agree on how to deal with the bullets above, only smaller modifications should be needed to the text.
ConnectionError should be added; SCTP priority should be removed Fix the inconsistency Add addRemote and removeRemote text related to MPTCP No action Mention Closed Event See item 1, no further action Update UDP-Lite description

the IP header can be obtained (GET_ECN.UDP(-Lite)). Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases <del> the local port reservation. </del> <ins> the local port reservation.  The Connection then issues a "Closed" event. </ins> Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close", except that the Connection will send <del> a ConnectionError Event rather than a Closed Event. </del> <ins> a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all


Question:
Takes care of item 5 and .
See discussion on
Provide a complete template that covers all functions/properties from the API. Indicate how the template should be used (e.g. leave out the parts that are not relevant for a particular protocol or include all fields and mark fields that are not relevant as such.
I'm wondering if this is really something that's in scope that we should cover. We do have the message properties section that explains how to implement various properties, but I think adding each property to every protocol mapping will be a huge amount of text that will be difficult to get exactly right.
I agree, we have added additional properties since we opened this issue to check the mapping and make sure we have a complete coverage. We should still be consistent in how we treat things though, and perhaps add a sentence that we do not describe all the properties for instance. I have made a pass through to check the mapping from the API to impl. draft for all the protocol mappings as a basis for making things consistent. Here is the summary. We cover the same actions and events for all the protocols with the exceptions that UDP Multicast does not cover the ConnectionError event and SCTP covers the Priority connection property. And MPTCP and UDP-lite are special as they refer back to the base protocols. There is one terminology inconsistency where the impl. draft refers to InitiateError and this has been generalized to EstablishmentError in the API Unless I missed something, there are only two actions that can be made on a connection that are not covered, addRemote and removeRemote. This is probably fine as they do not mean much for most of the protocols (or we could add them to be complete). We should perhaps mention how they relate to MPTCP though if we leave them out. We also do not cover the Preconnection.Rendezvous action. Again this may be fine as it is a bit special (or we can mention it for consistency.) For the events, we cover a subset with main focus on the connection related events. The Closed Event and some events related to connection setup are missing. As we cover ConnectionError we should perhaps cover the Closed event as well? We do not cover any of the Send or Receive events which seems fine. In relation to Connection and Message properties, we do not cover any of them except for the Connection priority covered for SCTP and we talk about some properties in connection to UDP-lite and MPTCP. SCTP also has support for partial reliability and unordered messages so not sure why the priority part was singled out and added. NAME any particular reasoning behind this part? Possibly we should remove the priority part for SCTP or discuss it in running text in a similar fashion as for UDP-lite and MPTCP We may want to update the UDP-lite description to also say something about what properties it supports over UDP. The current description sounds like it is a subset. Once we agree on how to deal with the bullets above, only smaller modifications should be needed to the text.
ConnectionError should be added; SCTP priority should be removed Fix the inconsistency Add addRemote and removeRemote text related to MPTCP No action Mention Closed Event See item 1, no further action Update UDP-Lite description

Calling "Close" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) releases the local port reservation and leaves the group. <ins> The Connection then issues a "Closed" Event. </ins> Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- <del> Lite)) is identical to calling "Close". </del> <ins> Lite)) is identical to calling "Close", except that the Connection will send a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific <del> Transport Property, such as the user timeout value, in a protocol- specific property called "tcp.userTimeoutValue" (see tcp-uto). </del> <ins> Transport Property, such as the user timeout value, in a Protocol- specific Property called "tcp.userTimeoutValue" (see tcp-uto). </ins> Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml) are reserved for protocol-specific </del> <ins> numbers/protocol-numbers.xhtml) are reserved for Protocol-specific </ins> Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation-


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying <del> stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </del> <ins> stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Protocol-specific Properties are defined in a transport- and implementation-specific way to permit more specialized protocol features to be used.  Too much reliance by an application on <del> protocol-specific Properties can significantly reduce the flexibility </del> <ins> Protocol-specific Properties can significantly reduce the flexibility </ins> of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that <del> Protocol Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </del> <ins> Protocol-specific Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </ins> The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or protocol- </del> <ins> These Message Properties may be generic properties or Protocol- </ins> specific Properties. For MessageContexts returned by send Events (see send-events) and


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

In the following cases, failure should be detected during pre- establishment: <del> A request by an application for Protocol Properties that cannot be </del> <ins> A request by an application for properties that cannot be </ins> satisfied by any of the available protocols.  For example, if an application requires "perMsgReliability", but no such feature is available in any protocol on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. <del> A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </del> <ins> A request by an application for properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </ins> "perMsgReliability", this mismatch should result in an error. To avoid allocating resources that are not finally needed, it is


Question:
We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.

implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For <del> protocol-specfic properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </del> <ins> Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </ins> If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that


Question:
URL Assuming there would be more protocols in the future and the minset functionalities will expand via extension or amendments. It would important to indicate if this architecture should is also extensible or it only supports on the minimum set referred. Definitely we haven't seen the future yet, but it would be important to express if we have considered such expansion of minimum functionalities.
To me, the current spec is based on minset that describes the common functions. So, the addition I would expect here is to say that there can be extensions and protocol-specific features.
I expect that if a common feature is added to the minset, then the architecture and API surface would also be extended to match.
LGTM modulo a nit

SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by <del> transport protocols RFC8923. </del> <ins> transport protocols RFC8923.  If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match. </ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via


Question:
URL Unless there is a description the figure, with directed and non-directed lines it is very hard to interpret the figure. I would recommend to at least add some reading guidance for the lines.
LGTM, thanks!Looks fine.

setting Connection and Message Properties in Pre-Establishment) or have been omitted for brevity and simplicity. <ins> In this diagram, the lifetime of a Connection object is broken into three phases: Pre-Establishment, the Established state, and Termination. Pre-Establishment is based around a Preconnection object, that contains various sub-objects that describe the properties and parameters of desired Connections (Local and Remote Endpoints, Transport Properties, and Security Parameters).  A Preconnection can be used to start listening for inbound connections, in which case a Listener object is created, or can be used to establish a new connection directly using Initiate() (for outbound connections) or Rendezvous() (for peer-to-peer connections). Once a Connection is in the Established state, an application can send and receive Message objects, and receive state updates. Closing or aborting a connection, either locally or from the peer, can terminate a connection. </ins> 4.1.1. Endpoint: An endpoint represents an identifier for one side of a


Question:
(sorry that it took me so long) This uses some text that is also in the interface draft.
This I would like us to discuss. Well I know we have discussed this before. As I am reading the Interface document after a long while and having read it along with the architecture document, I kind of strongly feel that the architecture document lack of description on framer and the states. These are mentioned and pictured in the architecture document but haven't been clear there. Hence, I kind of feel that we need to move this two sections to architecture document. Please discuss so that I can understand the reasoning of not doing so.
Regarding section 9.1.2, the framer description: I think it's good to be clear and complete in the API document, but I agree that framers should be appropriately described in the architecture document. I have the impression that the text in the -arch document on this matter may indeed be too short, while the text in the -interface document may be too long (although a little bit of repetition surely won't hurt here, it's good for this document to be understandable and clear on its own). Maybe some of it could be moved to -arch, or repeated there? Regarding section 11, Connection states: to me, this is fine as it is. Section 4.1 / figure 4 in the architecture document make state transitions pretty clear - and section 11 / figure 2 are just a more fine-grain look at these states as a way to explain exactly which Events will occur when. This seems needed in the API document, where all other Events and Actions are defined, and I would think that this is at a too detailed / fine-grain level for the architecture document.
NAME after giving it some more thoughts, I think your suggested approach should be fine , meaning we put more description of framer in the architecture document and leave the connection states to the Interface document.
NAME did you want to take a stab at this?
Looks great!

application. Framer: A Framer is a data translation layer that can be added to <del> a Connection to define how application-layer Messages are transmitted over a Protocol Stack.  This is particularly relevant when using a protocol that otherwise presents unstructured streams, such as TCP. </del> <ins> a Connection.  Framers allow extending a Connection's protocol stack to define how to encapsulate or encode outbound Messages, and how to decapsulate or decode inbound data into Messages.  In this way, message boundaries can be preserved when using a Connection object, even with a protocol that otherwise presents unstructured streams, such as TCP.  This is designed based on the fact that many of the current application protocols evolved over TCP, which does not provide message boundary preservation, and since many of these protocols require message boundaries to function, each application layer protocol has defined its own framing.  For example, when an HTTP application sends and receives HTTP messages over a byte-stream transport, it must parse the boundaries of HTTP messages from the stream of bytes. </ins> 4.1.6.


Question:
Feel free to approve or propose changes to improve this sentence in Arch.
BT: "I’m not convinced of the value of the glossary of terms, as it forwardrefs basically the entire document, and some of the definitions are so generic as to be potentially confusing (e.g. Event), so I think putting these up front reduces the document’s approachability and readability. I understand that some people like these (and other standards orgs make them mandatory, hi ETSI), so I won’t fight it." "Adding a sentence making it clear it’s safe to skip the glossary if you’re going to read the rest of the document would address my approachability concern completely. "

1.4. This subsection provides a glossary of key terms related to the <del> Transport Services architecture.  It provides a simple description of </del> <ins> Transport Services architecture.  It provides a short description of </ins> key terms that are later defined in this document. Application: An entity that uses the transport layer for end-to-


Question:
This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there. For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).
As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far. We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.

constraints on the selection and configuration of paths and protocols to establish a Connection with a remote endpoint.  A Connection represents a transport Protocol Stack on which data can be sent to <del> and received from a remote endpoint.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client), through listening on the Preconnection (i.e., passively opening, as in a server), or rendezvousing on the Preconnection (i.e. peer to peer establishment). </del> <ins> and/or received from a remote endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client), through listening on the Preconnection (i.e., passively opening, as in a server), or rendezvousing on the Preconnection (i.e. peer to peer establishment). </ins> Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message


Question:
This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there. For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).
As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far. We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.

5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data In case a unidirectional connection is requested, but the system should fall back to bidirectional transport if unidirectional connections are not supported by the transport protocol. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a


Question:
This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there. For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).
As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far. We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.

also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del> <ins> 5.2.6. </ins> Type: Preference


Question:
This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there. For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).
As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far. We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.

single underlying transport connection where possible.  This is not a strict requirement.  The default is to not have this option. <del> 5.2.6. </del> <ins> 5.2.7. </ins> Type: Boolean