search

kazuho / draft-kazuho-httpbis-priority

Other
6 stars 4 forks source link

Change initial to default #25

Closed rmarx closed 4 years ago

rmarx commented 5 years ago

Seems like that was more the intent

LPardue commented 5 years ago

The term initial was used on purpose to align with HTTP/2 section 5.5 e.g

   This document doesn't mandate a specific method for negotiating the
   use of an extension but notes that a setting (Section 6.5.2) could be
   used for that purpose.  If both peers set a value that indicates
   willingness to use the extension, then the extension can be used.  If a 
   setting is used for extension negotiation, the initial value MUST
   be defined in such a fashion that the extension is initially
   disabled.
rmarx commented 5 years ago

I am all for consistency :) Just feels weird, as IIUC in H3 there is no way to update this setting once the connection is established. Or maybe this is meant more to indicate connection resumption?

LPardue commented 5 years ago

Well now I see that H2 and H3 are inconsistent :(

From H2

SETTINGS_INITIAL_WINDOW_SIZE (0x4):  Indicates the sender's initial
      window size (in octets) for stream-level flow control.  The
      initial value is 2^16-1 (65,535) octets.

From H3

SETTINGS_MAX_HEADER_LIST_SIZE (0x6):  The default value is unlimited.
      See Section 5.1.1 for usage.

also

    All settings begin at an initial value, and are updated upon receipt
   of a SETTINGS frame.  For servers, the initial value of each client
   setting is the default value.

So, now I'm none the clearer on which is the better term.

kazuho commented 5 years ago

I prefer “Initial”.

An H2/H3 connection becomes usable before receiving a SETTINGS frame from the peer. Until then, the initial value is applied. It doesn’t matter for this particular settings value, though.

LPardue commented 4 years ago

The authors preferred initial, and this PR is rotted. Closing but reopen if you fee a strong need to try and convince us .