[art] Reviewing taps-impl-12

[Christian Amsüss <[e-mail]>]

Hello taps-impl authors,

I've had a look at Implementing Interfaces to Transport Services from
the point of view of a curious observer of the TAPS ecosystem without
actual hands-on experience. (Also, I thought I'd review this for the ART
review team -- I wasn't assigned, but still kept ART area issues in
mind, and none were even remotely encountered).

* "Connection establishment is only a local operation for a Datagram
  transport (e.g., UDP(-Lite))": I think the criterion is not Datagram
  transports but "transports without a handshake" or "connectionless
  protocols" as it is used later in the document.

* "In effect, each leaf node will send the same early application data,
  yet encoded (encrypted) differently on the wire.": There has been a
  warning on the privacy implications of using the same token on
  different paths; doesn't sending an identical 0-RTT message racingly
  on multiple transports cause similar correlation issues?

* 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.

* Framers: The <tt> paragraphs in Defining Message Framers and later
  might be formal language or pseudocode, I can't tell. It might help if
  the introduction stated something around names and signatures of
  signals and functions being expressed in pseudocode, and that
  identifiers in implementations are expected to be similar to those but
  following the conventions of the language they are implemented in.

* Is the content of messages always bytes? I certainly got that
  impression, but didn't see it explicitly either. (The "protocols that
  expose byte-streams" have that property visible in their name). When
  framers are used a lot, I can envision that at some point a message
  might not use data bytes at all any more, as all information in the
  underlying message is being dissected into protocol specific
  properties.

* UDP, ConnectionError: Would those soft errors contain additional
  information about the ICMP error code, and can an application expect
  to find the (partial) original datagram in the error?

* (More out of curiosity, with no expectation that this would find its
  way into the text unless you think I've hit a bug): In UDP Multicast
  Receive, which kind of ICMP notifications can come in there that would
  constitute a ConnectionError -- given that this transport does not
  send (and would thus usually not trigger any)?

* The most recent changes on the two linked Python implementations had
  me briefly worry that they might be out of date with their last
  changes around 2019/2020 -- but comparing -12 with -06 it seems that
  the document has been stable for quite a while (with many changes
  appearing editorial.

  This nicely matches my the overall impression of this document, which
  is that it looks mature and ready to implement.

Best regards, and thank you for the continuous work on this
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom