- Specific Transport Protocol Considerations
Each protocol that is supported by a Transport Services
implementation should have a well-defined API mapping.
This seems to be an odd statement. Of course, each of the common
protocols MUST have a well-defined API mapping, but also, that mapping
MUST be specified in the API definition document, or otherwise
applications couldn't use it in a standardized way. So why is the word
"should" used, and why is there not a reference at this point to the
API document that specifies these mappings?
Each protocol has a notion of Connectedness. Possible values for
Connectedness are:
"values" isn't the right word. Perhaps "Possible definitions of
Connectedness for various types of protocols are:"
I notice that the following protocols are mentioned in the document,
some seemingly as examples, but are not listed in sec. 10. What is
their status? Does the API definition state how to use them? If not,
why are they mentioned in the implementation document?
DTLS
HTTP
HTTP2/TLS/TCP
HTTP3/QUIC/UDP
QUIC
The absence of discussion of any of the HTTP request/response
protocols is particularly worrisome, as it suggests that there is no
defined way to use the API to use HTTP, and yet people write as if
implementations will support it.
From the review by Dale Worley: https://mailarchive.ietf.org/arch/msg/last-call/bpBk8QxZMLksr3ZuROtf2_BXYdI/
Note that indentation was lost by copy+pasting here - look at the edited version or the version at the URL to get a clearer view of what is being quoted.
Each protocol that is supported by a Transport Services
implementation should have a well-defined API mapping.
This seems to be an odd statement. Of course, each of the common
protocols MUST have a well-defined API mapping, but also, that mapping
MUST be specified in the API definition document, or otherwise
applications couldn't use it in a standardized way. So why is the word
"should" used, and why is there not a reference at this point to the
API document that specifies these mappings?
Each protocol has a notion of Connectedness. Possible values for
Connectedness are:
"values" isn't the right word. Perhaps "Possible definitions of
Connectedness for various types of protocols are:"
I notice that the following protocols are mentioned in the document,
some seemingly as examples, but are not listed in sec. 10. What is
their status? Does the API definition state how to use them? If not,
why are they mentioned in the implementation document?
DTLS
HTTP
HTTP2/TLS/TCP
HTTP3/QUIC/UDP
QUIC
The absence of discussion of any of the HTTP request/response
protocols is particularly worrisome, as it suggests that there is no
defined way to use the API to use HTTP, and yet people write as if
implementations will support it.
From the review by Dale Worley: https://mailarchive.ietf.org/arch/msg/last-call/bpBk8QxZMLksr3ZuROtf2_BXYdI/
Note that indentation was lost by copy+pasting here - look at the edited version or the version at the URL to get a clearer view of what is being quoted.