Re: HPACK padding

I meant that we would need to if we defined a new frame type.


On Fri, Feb 7, 2014 at 3:47 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Yup, which is "as per the frame type's usual disposition" (though I don't
> suggest that text).
> -=R
>
>
> On Fri, Feb 7, 2014 at 3:43 PM, Jeff Pinner <jpinner@twitter.com> wrote:
>
>> Another thing would be needing to describe how PADDING and flow control
>> are related.
>>
>>
>> On Fri, Feb 7, 2014 at 1:30 PM, Hasan Khalil <mian.hasan.khalil@gmail.com
>> > wrote:
>>
>>> As previously discussed, padding granularity should be at the byte
>>> level, with a minimum nonzero pad amount of one byte. If we simply have a
>>> PADDING frame, the minimum nonzero pad amount is eight bytes.
>>>
>>>
>>> On Fri Feb 07 2014 at 3:09:11 PM, Osama Mazahir <OSAMAM@microsoft.com>
>>> wrote:
>>>
>>>> Wouldn't it be easier just to have a separate PADDING frame instead of
>>>> having flags, and associated logic, in HEADERS, CONTINUATION and DATA
>>>> frames?
>>>>
>>>> The objective is not to obfuscate the frames, but to allow varying the
>>>> resultant ciphertext size.
>>>>
>>>> It seems easier to code such that you construct your frames normally as
>>>> is today.  And then append a discrete PADDING frame, if desired.  And then
>>>> go through the standard TLS code.  On the final receiver, you just add a
>>>> switch-case for the PADDING frame type and drop it on the floor.
>>>>
>>>> -----Original Message-----
>>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>>> Sent: Friday, February 7, 2014 9:43 AM
>>>> To: RUELLAN Herve
>>>> Cc: ietf-http-wg@w3.org
>>>> Subject: Re: HPACK padding
>>>>
>>>> I'm going to do this.  If I hear screams, I have the power to back out
>>>> the relevant commits.
>>>>
>>>> On 7 February 2014 07:43, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
>>>> wrote:
>>>> > For solving issue #346, HPACK padding, Roberto proposed to extend the
>>>> padding mechanism for DATA frames to HEADER and CONTINUATION frames.
>>>> >
>>>> > I think that makes sense : we have only one padding mechanism. As
>>>> such, we have one central location for deciding whether padding is
>>>> necessary in regards of all the available information.
>>>> >
>>>> > Any though?
>>>> >
>>>> > Hervé.
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>
>