Subject: [hybi] consensus call on ability to announce max frame size

From: Gabriel Montenegro <[email-masked]>
Date: Sat, 30 Jul 2011 03:32:58 +0000

At the meeting and on the mailing list leading up to it, the chairs saw consensus for the following action:

                Add ability to announce max frame size by  both client and server

We're confirming on the mailing list, and will declare this consensus call final by next Friday Aug 5.

Thanks,

Gabriel and Salvatore
HyBi co-chairs

---

From: John Tamplin <[email-masked]>
Date: Fri, 29 Jul 2011 23:40:50 -0400

On Fri, Jul 29, 2011 at 11:32 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  At the meeting and on the mailing list leading up to it, the chairs saw
> consensus for the following action:****
>
> ** **
>
>                 Add ability to announce max frame size by  both client and
> server****
>
> ** **
>
> We’re confirming on the mailing list, and will declare this consensus call
> final by next Friday Aug 5.
>
> **
>

SGTM.  Will we have a concrete proposal, or does that come after declaring
consensus?

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Gabriel Montenegro <[email-masked]>
Date: Sat, 30 Jul 2011 04:07:42 +0000

Concrete proposal is welcome. Of course, if something happens and consensus is not ultimately declared, it will not be taken up.

But if you have something, please do share it.

Thanks,

Gabriel

From: John Tamplin [mailto:[email-masked]]
Sent: Friday, July 29, 2011 23:41
To: Gabriel Montenegro
Cc: Server-Initiated HTTP
Subject: Re: [hybi] consensus call on ability to announce max frame size

On Fri, Jul 29, 2011 at 11:32 PM, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
At the meeting and on the mailing list leading up to it, the chairs saw consensus for the following action:

We’re confirming on the mailing list, and will declare this consensus call final by next Friday Aug 5.

SGTM.  Will we have a concrete proposal, or does that come after declaring consensus?

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 30 Jul 2011 17:12:15 +1000

+1 on the ability to declare a maximum acceptable frame sizes (this
can be implemented transparently).
-1 on the ability to declare a maximum acceptable message size (as
you'd have to tell the application what that is).

On 30 July 2011 14:07, Gabriel Montenegro
<[email-masked]> wrote:
> Concrete proposal is welcome. Of course, if something happens and consensus
> is not ultimately declared, it will not be taken up.
>
>
>
> On Fri, Jul 29, 2011 at 11:32 PM, Gabriel Montenegro
> <[email-masked]> wrote:
>
> consensus for the following action:
>
>
>
> server
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 30 Jul 2011 09:31:38 +0200

> you'd have to tell the application what that is).

I'd also argue that HTTP has been living for a decade with support for
chunked encoding which does not set a limit on chunk size nor on message
size and has not had any trouble with that. I'm still in favor of being
able to declare a max frame size to save fairness for later mux support,
but limited message size does not seem useful to me either.

Willy

---

From: John Tamplin <[email-masked]>
Date: Sat, 30 Jul 2011 03:46:04 -0400

> but limited message size does not seem useful to me either.

I see no mention of maximum message size in this consensus call, only
maximum frame size.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 30 Jul 2011 10:37:17 +0200

> I see no mention of maximum message size in this consensus call, only

Agreed, but as Greg mentionned it, I expressed my opinion on this
point too. I know too well how dicussion subjects diverge and how
some solutions can be replaced with other ones in this WG ;-)

Cheers,
Willy

---

From: "Thomson, Martin" <[email-masked]>
Date: Sat, 30 Jul 2011 21:34:05 +0800

>                 Add ability to announce max frame size by  both client 

Given that there is no constraint on message size, this capability is pointless.  Any peer that receives this indication does not need to change their behaviour in any meaningful way.  Messages of any size can be sent regardless of what frame size is supported.

That said, such a negotiation might be crucial to an effective multiplexing scheme.  I suggest that this be deferred and included as part of the multiplexing work.

--Martin

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Sun, 31 Jul 2011 06:58:30 +0100

> Add ability to announce max frame size by both client and server

I think this is bogus, but it's needn't create problems.  Better to have 
removed the really really bogus 63-bit frame length and replace with 
something smaller that doesn't need to be "patched" with an "MTU".

Anyway the only thing is it would be very good to write it up so that 
implementors don't get the idea they are being told to buffer atomic 
frames.  Otherwise this kind of talk would naturally put you in mind of 
that kind of code with its attendant limitations.

-Andy

---

From: Paul Colomiets <[email-masked]>
Date: Sun, 31 Jul 2011 15:25:17 +0300

>                 Add ability to announce max frame size by  both client and server

+1 on announcing both max frame size and max message size. Unlike some
folks here
think, there *is* limit on message size in HTTP. That's reason why
Expect header exists.

-- 
Paul

---

From: Julian Reschke <[email-masked]>
Date: Sun, 31 Jul 2011 15:07:39 +0200

> think, there *is* limit on message size in HTTP. That's reason why

Hmm, no.

*Implementations* can have limits, and Expect can help dealing with 
that. But it's not a protocol limitation.

Best regards, Julian

---

From: Paul Colomiets <[email-masked]>
Date: Sun, 31 Jul 2011 16:16:25 +0300

On Sun, Jul 31, 2011 at 4:07 PM, Julian Reschke <[email-masked]> wrote:
> *Implementations* can have limits, and Expect can help dealing with that.
> But it's not a protocol limitation.

Sure, that's what we talk about here. Expect header is a way to announce
limitation of particular server setup in HTTP.

-- 
Paul

---

From: Julian Reschke <[email-masked]>
Date: Sun, 31 Jul 2011 15:21:05 +0200

On 2011-07-31 15:16, Paul Colomiets wrote:
> On Sun, Jul 31, 2011 at 4:07 PM, Julian Reschke<[email-masked]>  wrote:

Hmm, how exactly does Expect help here?

You can do Expect: 100-continue in the client, and then the server has a 
chance to reject the request (such as a huge PUT), but that's it.

Best regards, Julian

---

From: Paul Colomiets <[email-masked]>
Date: Sun, 31 Jul 2011 18:37:30 +0300

> chance to reject the request (such as a huge PUT), but that's it.

I don't see you point Julian. That's exactly what max message size
announcement can do. It says that messages larger than specified will be
rejected. Then how API reacts on that is another story.

Of course maximum frame size is something different. It asks sender
to split longer messages to chunks of specified size. Thinking more
about this, I think I'm opposed to the idea of specifing frame size. The
problem with frame size limit, is that it gives lazy developers a false
impression that they can set buffer size to the maximum frame size.
In majority cases it's simply not true. And it's not very hard to split
message into frames in the intermediary either.

+1 for announcing message size
-0 for announcing frame size

-- 
Paul