jiebi/CodeConvo huggingface dataset:
Code change:
I'm not quite sure what I meant by "Only full coverage is guaranteed, any other requests are advisory". I assume we mean that even if a partial checksum is requested you get full coverage because requesting partial coverage and getting no checksum doesn't seem right...?
Exactly, and you made it clearer. Thanks!

Related discussion:
text: Integer (non-negative with -1 as special value) <del> full coverage </del> <ins> -1 (full coverage) </ins> This property specifies the minimum length of the section of the Message, starting from byte 0, that the application requires to be
Code change:
I'm not quite sure what I meant by "Only full coverage is guaranteed, any other requests are advisory". I assume we mean that even if a partial checksum is requested you get full coverage because requesting partial coverage and getting no checksum doesn't seem right...?
Exactly, and you made it clearer. Thanks!

Related discussion:
text: to specify options for simple integrity protection via checksums.  A value of 0 means that no checksum is required, and -1 means that the entire Message is protected by a checksum.  Only full coverage is <del> guaranteed, any other requests are advisory. </del> <ins> guaranteed, any other requests are advisory, meaning that full coverage is applied anyway. </ins> 7.4.7.
Code change:
In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!

Related discussion:
text: Specify a Local Endpoint using a local interface name and local port: <ins> As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the "Interface Instance or Type" Selection Property, see prop- interface.  However, if the application specifies Selection Properties which are inconsistent with the Local Endpoint, this will result in an error once the application attempts to open a Connection. </ins> Specify a Local Endpoint using a STUN server: Specify a Local Endpoint using a Any-Source Multicast group to join
Code change:
In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!

Related discussion:
text: higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. <del> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> A Stopped Event occurs after the Listener has stopped listening.
Code change:
In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!

Related discussion:
text: contained within the RendezvousDone<> Event, and is ready to use as soon as it is passed to the application via the Event. <del> An RendezvousError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </del> <ins> An RendezvousError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </ins> When using some NAT traversal protocols, e.g., Interactive Connectivity Establishment (ICE) RFC5245, it is expected that the
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: The Transport Services architecture evolves this general model of interaction, aiming to both modernize the API surface presented to applications by the transport layer and enrich the capabilities of <del> the Transport System implementation.  It combines interfaces for </del> <ins> the Transport Services implementation.  It combines interfaces for </ins> multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: make use of the data that arrived; the ability to manage dependencies between messages, when the <del> Transport System could decide to not deliver a message, either following packet loss or because it has missed a deadline.  In particular, this can avoid (re-)sending data that relies on a </del> <ins> Transport Services system could decide to not deliver a message, either following packet loss or because it has missed a deadline. In particular, this can avoid (re-)sending data that relies on a </ins> previous transmission that was never received. the ability to automatically assign messages and connections to
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: Transport Properties: Transport Properties allow the application to express their requirements, prohibitions, and preferences and <del> configure the Transport System.  There are three kinds of </del> <ins> configure the Transport Services system.  There are three kinds of </ins> Transport Properties: Selection Properties (preestablishment) that can only be
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later. Changes made to Connection Properties after Connection establishment take effect on a best-effort basis. </del> <ins> behavior of the Transport Services system; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection Properties after Connection establishment take effect on a best- effort basis. </ins> 4.1.3.
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: Properties when sending.) Abort: The action the application takes on a Connection to <del> indicate a Close and also indicate that the Transport System SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </del> <ins> indicate a Close and also indicate that the Transport Services system SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </ins> cleaning up state. 4.2.
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. <del> Specifically, a Transport System would consider protocols </del> <ins> Specifically, a Transport Services system would consider protocols </ins> identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS
Code change:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Related discussion:
text: protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides efficiency and convenience for the application, since the Transport <del> System implementation can automatically optimize behavior. </del> <ins> Services implementation can automatically optimize behavior. </ins> There are several reasons, however, that an application might want to explicitly isolate some Connections.  These reasons include:
Code change:
this should
Right there was a typo: Replacing the last 2 sentences, the last sentence ought to be: " Endpoints should avoid IP fragmentation ({{!RFC8304}}) and when used with transports running over IP version 4 the Don't Fragment bit will be set." These are two separate issues that a stack implementor has to decide to do: (1) Decide if the endpoint will fragment; (2) decide if the path can fragment the fragments. In some OS this will be bundled together, in other OS they will not.
Discussed on the interim call. The name probably could be much better. We also want to model in the text the atomicity property of UDP transfers.
This text is broken: section 5.1 / o Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation. Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing. Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in [RFC8304]). / we need to rewrite
Waiting to see exactly how DPLPMTUD finishes WGLC ... will be ready for text in Jan.
Reads much better except the last broken sentence

Related discussion:
text: than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </del> <ins> Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.
Code change:
Fig. 4 isn't fully consistent with sec. 12 in the API document. A few things that stood out to me: InitiateWithSend() is missing. I can see that this isn't trying to cover everything, but randomly leaving some things out makes it all a bit confusing IMO... "Connection Received" reads as if it should really be the "ConnectionReceived<>" event in the API doc. So I would put these events there and use the "<>" to indicate them. Same with "Closed"... this is actually an event, so why not write it as such, with the "<>"? RendezvousDone is missing... should we include all events or not? Of course that would then also require adding Sent, Received, ... maybe it would be better to indicate that events are events, but put a statement somewhere saying that not all events are shown. In the same vein, I would replace "Connection Ready" with "Ready<>" "Conn. Finished" reads as if it might be an event, but this event doesn't exist... I would just remove this
I've added InitiateWithSend(), and removed Conn. Finished; you're right, these are confusing. This diagram does not use the API draft's event notation, and I'm not sure it makes sense to introduce it here -- it would require a bit more expository text only to make a diagram that is an attempt to provide a high-level view provide a... less high-level view. (The expository text now says "... some actions ... have been omitted for brevity and simplicity" and I think that's the right approach.)
Agreed!
lgtm

Related discussion:
text: actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), while others are optional (e.g., setting Connection and Message Properties in Pre-Establishment) or <del> have been omitted for brevity. </del> <ins> have been omitted for brevity and simplicity. </ins> 4.1.1.