-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specific Transport Protocol Considerations #1150
Labels
Comments
This is pointing to future work on other mappings documents. |
Discussed on TAPS Call on 15th May and this is future work that seems possible within the architcture, but not for this document. |
#1440 addresses:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: