More applicability edits #153
Conversation
The implication here was that this was universal, but it is merely common. I also split the very long paragraph to improve readability.
So I reworded it.
CID used to be optional, now it's zero-length. I've expanded the text here some.
My text, my fault, but still
| Probing packets, which cannot carry application data, can be sent on multiple | ||
| paths at once. Probing packets can be used perform address validation, measure | ||
| path characteristics as input for the switching decision, or prime the | ||
| congestion controller in preparation for switching to the new path. |
There was a problem hiding this comment.
Thanks this wording is good now :-)
| connection migration. Padding can also be used by an application to reduce | ||
| leakage of information about the data that is sent. A QUIC implementation can | ||
| expose an interface that allows an application layer to specify how to apply | ||
| padding. |
There was a problem hiding this comment.
You removed the note about packet length of 1200 bytes. This information was there as this section is kind of describing everything you might want to know about packetization. However, I guess this point is really not important for an application. So I'm fine removing it.
There was a problem hiding this comment.
Yeah, it was not precise enough for me and I don't think that it has much bearing on usage (it's more for implementation and so the core spec can deal with that).
| sets of types: one for QUIC internal problems that might lead to connection | ||
| closure, and one for closures initiated by the application. An application | ||
| using QUIC can define application-specific error codes (see, for example, | ||
| {{QUIC-HTTP}}, Section 8.1). |
There was a problem hiding this comment.
Why did you remove this sentence?
In the case of a grateful shut-down initiated by the application
after application layer negotiation, a NO_ERROR code is expected
Not that the point is super important but wondering is there is an actual reason to remove it...?
There was a problem hiding this comment.
The NO_ERROR thing is an HTTP error code, which isn't generic advice. But more concretely, when you gracefully shutdown, you might agree to stay quite and run down the idle timeout instead. Or there might be other ways of signaling clean shutdown prior to sending CONNECTION_CLOSE. I just thought that this was too specific.
There was a problem hiding this comment.
Ah, didn't realise that an HTTP errs code. Do we need to say more here?
There was a problem hiding this comment.
I don't think so. This is pretty well treated in the main spec and you have discussion on idle timeouts that seems ample.
draft-ietf-quic-applicability.md
Outdated
| The third stage completes the process by enabling validation of the negotiation | ||
| version as though the new version were disabled. | ||
| The third stage completes the process by enabling validation of the negotiated | ||
| version with the assumption that the new version is fully available. |
There was a problem hiding this comment.
Actually I'm not sure here. If I remember correctly this text was provided by someone else and it's not entirely clear to me anymore what this stage is supposed to achieve....
There was a problem hiding this comment.
This was my text originally. But I got it backwards. You can't complete an upgrade that adds a new version and end with the assumption that the new version is disabled. I probably meant "enabled".
There was a problem hiding this comment.
Ah okay. However, what's actually meant by validation in this phase?
There was a problem hiding this comment.
Validation being authentication of the values. Maybe I can use that instead.
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.