Move Transport Properties text and close #373

[philsbln]

closes #373

[tfpauly]

Please have these be a sub-section of the Pre-Establishment. This should not be a top-level phase of the connection.

[philsbln]

This was my first idea too, but it did not work out: In Pre-Establishment, we have a detailed description (two lengthy bullet points out of five) how selection and connection properties work in detail. All ways of rewriting Pre-Establishment to fit the high-level concept of Transport Properties there look awkward to me.

We moved that one around a lot just to avoid do making it an API Concept - but it is.

[tfpauly]

Please see my other comment. I think these still belong with Preconnection, as the text indicates.

[philsbln]

The concept of Transport Properties spans all connection objects – not only the Preconnection – and therefore I would prefer not to put them in the Preconnection.
Nevertheless, they are most often used on the Preconnection and the Selection Properties work only on this one.

[britram]

Agreed, this rearrangement is not great, but I don't like any of the alternatives either.

[tfpauly]

I propose this diff instead—just indent Transport Properties where it is, as a sub-part of Preconnection:

-* Transport Properties: Transport Properties can be specified as part of a Preconnection to allow the application to configure the Transport System and express their requirements, prohibitions, and preferences. There are three kinds of Transport Properties: 
+  * Transport Properties: Transport Properties can be specified as part of a Preconnection to allow the application to configure the Transport System and express their requirements, prohibitions, and preferences. There are three kinds of Transport Properties: 
 
-  * Selection Properties ({{preestablishment}})
-  * Connection Properties ({{preestablishment}})
-  * and Message Properties ({{datatransfer}}); note that Message Properties can also be specified during data transfer to affect specific Messages.
+    * Selection Properties ({{preestablishment}})
+    * Connection Properties ({{preestablishment}})
+    * and Message Properties ({{datatransfer}}); note that Message Properties can also be specified during data transfer to affect specific Messages.

[philsbln]

Tried that… looks strange:

4.1.1.  Connection Objects

   o  Preconnection: A Preconnection object is a representation of a
      potential connection.  It has state that describes parameters of a
      Connection that might exist in the future: the Local Endpoint from
      which that Connection will be established, the Remote Endpoint
      (Section 4.1.2) to which it will connect, and Selection Properties
      (Section 4.1.2) that influence the paths and protocols a
      Connection will use.  A Preconnection can be fully specified such
      that it represents a single possible Connection, or it can be
      partially specified such that it represents a family of possible
      Connections.  The Local Endpoint (Section 4.1.2) MUST be specified
      if the Preconnection is used to Listen for incoming connections.
      The Local Endpoint is OPTIONAL if it is used to Initiate
      connections.  The Remote Endpoint MUST be specified in the
      Preconnection that is used to Initiate connections.  The Remote
      Endpoint is OPTIONAL if it is used to Listen for incoming
      connections.  The Local Endpoint and the Remote Endpoint MUST both
      be specified if a peer-to-peer Rendezvous is to occur based on the
      Preconnection.

      *  Transport Properties can be specified to allow the application
         to configure the Transport System and express their




Pauly, et al.             Expires May 29, 2020                 [Page 14]

Internet-Draft              TAPS Architecture              November 2019


         requirements, prohibitions, and preferences.  There are three
         kinds of Transport Properties:

         +  Selection Properties (Section 4.1.2) that can only be
            specified as part of a Preconnection.

         +  Connection Properties (Section 4.1.2) that may be changed on
            the Connection.

         +  and Message Properties (Section 4.1.4) that can also be
            specified during data transfer to affect specific Messages.

[britram]

eh... it looks a little odd but it is technically more correct.

[abrunstrom]

So the whole point of this text is to introduce the term Transport Properties I think. Otherwise we could have just removed it as the three kinds are described in detail in later sections. Perhaps we can just insert this as running text at the end of the Preconnection description instead to make it look less awkward. Something like:

Selection Properties (Section 4.1.2) can only be specified as part of a Preconnection. Connection Properties (Section 4.1.2) may also be specified as part of a Preconnection, but may also be changed on the Connection. Together with Message Properties (Section 4.1.4), which can also be specified during data transfer to affect specific Messages, they are the three kinds of Transport Properties that an application can specify to configure the Transport System and express its requirements, prohibitions, and preferences.

[philsbln]

I double-checked with the interface: there. transport properties are also an object that is passed to the preconnection and that can retrieved from a connection.
Therefore, I made it a Connection Object and slightly rephrased the text.

Does this work better?

[abrunstrom]

This is very similar to where we started I think, so did not help much for me unfortunately. I still do not think it fits as a Connection Object on the same level as the rest. What did you think about my suggestion to introduce it in running text as part of the description of the Preconnection?

[philsbln]

@abrunstrom I thought about your suggestion, but my problem with that is that Transport Properties are actually:

1. An actual Object in the API
2. Also used for introspecting and manipulating Connections

Therefore, putting them into the Preconnection seems wrong to me.