jiebi/CodeConvo huggingface dataset:
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for <del> aborting Connection" (see timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del> <ins> aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 9. <del> The application can set per-connection Protocol Properties (see protocol-props).  Certain Procotol Properties may be read-only, on a protocol- and property-specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </del> <ins> 9.1. The application can set per-connection Properties.  Certain Connection Properties may be read-only, on a protocol- and property- specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </ins> At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: Depending on the status of the connection, the queried Connection Properties will include different information: <ins> [TODO: turn this list into actual properties or move up into the explaining text] </ins> The status of the connection, which can be one of the following: Establishing, Established, Closing, or Closed.
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 12. <del> Having discussed Transport Properties in connection-props and listed a number of Message Properties ("Ordered", "Idempotent" etc.) in message-props, we now provide a complete overview of a transport system's defined Transport Properties. Properties are structured in two ways: </del> <ins> Having discussed Selection Properties in selection-props, Connection Properties connection-props, and Message Properties (message-props), we now provide a complete overview of a transport system's defined Transport Properties. </ins> <del> By how they influence the transport system, which leads to a classification into "Selection Properties", "Protocol Properties", "Control Properties" and "Intents". </del> <ins> Transport Properties are structured by the phase and object they are applied: - Selection Properties apply to Preconnections - see selection-props - Connections Properties apply to Connections - see connection-props - Messages Properties apply to Messages - see </ins> <del> By the object they can be applied to: Preconnections, see connection-props, Connections, see introspection, and Messages, see message-props. Because some properties can be applied or queried on multiple objects, all Transport Properties are organized within a single namespace. </del> <ins> All Transport Properties are organized within a single namespace. This enables setting them as defaults in earlier stages and querying them in later stages: - Connections Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages. </ins> Note that it is possible for a set of specified Transport Properties to be internally inconsistent, or to be inconsistent with the later
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 12.2. <del> Transport Properties - whether they apply to connections, preconnections, or messages - differ in the way they affect the transport system and protocols exposed through the transport system. The classification proposed below emphasizes two aspects of how properties affect the transport system, so applications know what to expect: Whether properties affect protocols exposed through the transport system (Protocol Properties) or the transport system itself (Control Properties) Whether properties have a clearly defined behavior that is likely to be invariant across implementations and environments (Protocol Properties and Control Properties) or whether the properties are interpreted by the transport system to provide a best effort service that matches the application needs as closely as possible (Intents). </del> <ins> [TODO: This section is mostly obsolete due to our consensus on how to structure properties - double-check whether text needs to be moved and delete this section afterwards] </ins> 12.2.1.
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 12.3.11. <del> Control Property [TODO: Discuss] Boolean Preconnection, Connection This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The default is to have this option. </del> <ins> Boolean Connection Property - see conn-retrans-notify. </ins> 12.3.12. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". </del> <ins> Integer Connection Property - see </ins> 12.3.13. <del> Control Property [TODO: Discuss] Boolean Preconnection, Connection This property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  When set to true, received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The default is not to have this option. </del> <ins> Boolean Connection Property - see </ins> 12.3.14.
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 12.3.16. <del> Protocol Property (Generic) Integer Connection This property specifies the part of the received data that needs to be covered by a checksum.  It is given in Bytes.  A value of 0 means that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. </del> <ins> Integer Connection Property - see </ins> 12.3.17.
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 12.3.21. <del> Protocol Property (Generic) Integer Connection This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. </del> <ins> Integer Connection Property - see </ins> 12.3.22. [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't <del> need both, so we should make a decision.] </del> <ins> need both, so we should make a decision. @mwelzl - These are really two different things @philsbln] </ins> Integer Message Property - see msg-niceness.
Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: 12.3.23. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> Integer Connection Property - see </ins> 12.3.24. <del> Protocol Property (Generic) / Control Property [TODO: Discuss] Enum Preconnection, Connection This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. </del> <ins> Enum Connection Property - see </ins> 12.3.25. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.26. <del> Protocol Property (Generic) Integer Connection (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  This property is read- only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.27. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent. This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.28. <del> Protocol Property (Generic) Integer Connection (read only) This numeric property represents the maximum Message size that can be received.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.29.
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: used to fine-tune the eventually established connection.  These Connection Properties can also be used to monitor and fine-tune established connections.  The behavior of the selected protocol <del> stack(s) when sending Messages is controlled by Message Context Properties message-props. Collectively, Selection, Connection, and Message Context Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </del> <ins> stack(s) when sending Messages is controlled by Message Properties message-props. Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </ins> Transport Properties can have one of a set of data types:
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: Initiate. An InitiateError occurs either when the set of transport properties <del> and cryptographic parameters cannot be fulfilled on a Connection for </del> <ins> and security parameters cannot be fulfilled on a Connection for </ins> initiation (e.g. the set of available Paths and/or Protocol Stacks meeting the constraints is empty) or reconciled with the local and/or remote endpoints; when the remote specifier cannot be resolved; or
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: Applications may need to annotate the Messages they send with extra information to control how data is scheduled and processed by the <del> transport protocols in the Connection.  A messageContext object contains parameters for sending Messages, and can be passed to the </del> <ins> transport protocols in the Connection.  A MessageContext object contains properties for sending Messages, and can be passed to the </ins> Send Action.  Note that these properties are per-Message, not per- Send if partial Messages are sent (send-partial).  All data blocks associated with a single Message share properties.  For example, it
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is <del> equivalent to passing a default messageContext with not values added. </del> <ins> equivalent to passing a default MessageContext with not values added. </ins> If an application wants to override Message Properties for a specific <del> message, it can acquire an empty messageContext Object and add all </del> <ins> message, it can acquire an empty MessageContext Object and add all </ins> desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties. <del> Parameters may be added to a messageContext object only before the </del> <ins> Properties may be added to a MessageContext object only before the </ins> context is used for sending.  Once a messageContext has been used <del> with a Send call, modifying any of its parameters is invalid. </del> <ins> with a Send call, modifying any of its properties is invalid. </ins> Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <del> The following Message Context Parameters are supported: </del> <ins> The following Message Properties are supported: </ins> 7.3.1.
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: The following example sends a Message in two separate calls to Send. <del> All messageData sent with the same messageContext object will be treated as belonging to the same Message, and will constitute an in- order series until the endOfMessage is marked.  Once the end of the Message is marked, the messageContext object may be re-used as a new Message with identical parameters. </del> <ins> All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked.  Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters. </ins> 7.5.
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: invoke Receive again. Multiple invocations of ReceivedPartial deliver data for the same <del> Message by passing the same messageContext, until the endOfMessage </del> <ins> Message by passing the same MessageContext, until the endOfMessage </ins> flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages.
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError instead (see termination). <del> The ReceiveError event passes an optional associated messageContext. </del> <ins> The ReceiveError event passes an optional associated MessageContext. </ins> This may indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed.
Code change:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Related discussion:
text: RFC7657 apply. The Capacity Profile for a selected protocol stack may be modified on <del> a per-Message basis using the Transmission Profile Message Context Property; see send-profile. </del> <ins> a per-Message basis using the Transmission Profile Message Property; see send-profile. </ins> 9.2.