Re: HPACK padding

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é.
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>