let's consider it this way.. has any implementation found FRAME_TOO_LARGE to be useful (outside of the case of implementations not wanting to handle frames > 64KB which is now not a factor)? If not, then it should go. If so, then I guess it should stay. On Wed, Jun 19, 2013 at 2:05 PM, James M Snell <jasnell@gmail.com> wrote: > For now, in the implementation draft, can we keep this focused on whether > or not to rename this one existing error code rather than expand into too > much philosophical debate about error codes in general? We can refine the > error code mechanism if necessary later on. > On Jun 19, 2013 11:00 AM, "Martin Thomson" <martin.thomson@gmail.com> > wrote: > >> On 19 June 2013 10:28, William Chan (陈智昌) <willchan@chromium.org> wrote: >> > Actionable difference: it tells you what part of your stack to debug. >> > PROTOCOL_ERROR is terrible :( Everytime we generate a PROTOCOL_ERROR, we >> > have felt we wanted to add a debug string (that opaque byte sequence we >> > discussed earlier) so we could figure out what was wrong. >> >> I thought that was the reason you wanted to put the opaque stuff in the >> body. >> >> The reason I'm pushing back is that it is possible to spend error code >> bits on any amount of subdivision of the PROTOCOL_ERROR space. Do you >> want one for the case where someone didn't echo the bytes of a PING? >> Or when they decide to send something else rather than continuing a >> HEADERS block? Or any of the many current and future >> your-implementation-is-broken cases? Ultimately, this just leads to a >> blowout in error codes, to no good end. >> >>
Received on Wednesday, 19 June 2013 18:15:48 UTC