Subject: [core] resource-directory: Considerations for TCP

From: Christian Amsüss <[email-masked]>
Date: Wed, 16 Nov 2016 09:21:36 +0100

Hello RD authors,

out of a protocol-negotiation discussion[1] with Bill there came points
I'd like to bring up with RD related to the new protocols introduced in
tcp-tls regarding the `con` parameter.

* For TCP connections with usually random source ports, the `con`
  parameter will be practically required. I'd suggest to add a note
  there, a la "(This parameter is compulsory when the directory is
  filled by a third party such as a commissioning tool), and practically
  required for protcols like TCP where outgoing and incoming
  communication use different addresses.

* For alternative transports in protocol-negotiation, path components
  are allowed in the `at` paramter, even though the currently
  in-progress protocols do not allow a path to be part of the base
  address. This leads to asymmetries with con.

  I'm not sure whether there can be protocols that have a path component
  in their base address (resolving a `/sensor/temp` reference would be
  really awkward in such a situation), but allowing for the context
  parameter to be a full URI (which would not necessarily allow it for
  the existing protocols) would keep the door open if someone figures
  out something very (or dangerously?) clever later.

  No matter whether or not paths are allowed, the same reasoning should
  be applicable to both `con` and `at`, so if there has been discussion on
  this earlier, I think it'd be helpful to point it out because it's
  probably applicable to `at` as well.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/K41POA2T1ZxaUz6O1HYmgLUsfeQ

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614