Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-07.txt

[Takeshi Yoshino <[e-mail]>]

Hi Dario,

Thanks for review.

On Fri, Mar 29, 2013 at 1:41 AM, Dario Crivelli <
[e-mail]> wrote:

> We know from RFC4655 (and also from the permessage-deflate extension case)
> that when a server accepts a PMCE offer, it can use, in the response,
> parameters different from those used in the offer;
>  as a consequence, the extension specification should determine when the
> response parameters are legal with respect to the offer.
> In the description of the general negotiation mechanism, in paragraph 4,
> as far as I can see, this is not restated explicitly.
> I suggest restating that, though redundantly, because the description of
> the offering/acceptance mechanism may be misleading.
> In fact, the mechanism allows the client to include multiple offers of the
> same PMCE with different parameters;
> so, this may deceive one into thinking that the acceptance only consists
> in the server choosing one of the offerings as is, with no further freedom
> to use different parameters in the response.
>

Added a sentence "The element doesn't need to exactly the same as one of
the received offers." and one example.


>  In paragraph 6.2 the following form is used several times:
> "If a server accepts an offer with ..."
> I think that the concept of "accepting an offer" should only pertain to
> paragraph 6.1.
> In paragraph 6.2 we are referring to the configuration parameters already
> agreed-upon.
> I see that in paragraph 4 there is a mention to
> "the configuration parameters of the PMCE to use in detail"
> which would be a better reference point, although it is not formally
> defined.
> Do you think that introducing a concept similar to the _Extensions In Use_
> of RFC6455 would be worthwhile?
>
>
I'll introduce a term "agreed parameter" and use it there.


>
> I'm still concerned about how multiple extensions can coexist and how this
> specification can interoperate with specifications of other extensions.
> With reference to paragraph 5.1, as far as this specification is meant as
> a specialization of RFC6455, it is clear how the indicated steps should
> replace the corresponding base steps in RFC6455
> (even though RFC6455 was not expressed in terms of steps).
> However, the specification in paragraph 5.1 replaces the base steps from
> the "payload data portion of the original message" to the frames being sent.
> It seems to me that this formulation excludes in advance the cooperation
> with any other extension, otherwise conflicts in the two specifications
> would arise and it might not be obvious how the two specifications should
> merge.
>
>
Changed the text considering the case there're other extensions next to the
PMCE.

Maybe still need more work but for now.


> On the other hand, I think it is obvious to all of us that a PMCE should
> only operate on the message payload
>

Yes. Added some text to state that.


> and should not interfere with any extension to be applied subsequently
> (operating either on the payload or on the frames), provided that it
> doesn't conflict on the use of the RSV1 bit.
>

Yes. Except for fragmentation change.


>  I'm not sure if the current specification conveys this idea.
>
>
Hmm, ... what kind of thing do you think we should say?


> By the way, in paragraph 4 it is said that an extension can be "applied to
> output of" another extension;
> however, in RFC6455 I can only find the concept of an "order of
> operations" (in 9.1), which seems to me a broader one.
>
>
Yes. Extension specification in RFC 6455 is very brief. Shall we redefine
it well here? Hmm


>
> Regards
> Dario Crivelli
>
>
>
>
>
>> Message: 2
>> Date: Tue, 19 Mar 2013 17:36:48 +0900
>> From: Takeshi Yoshino <[e-mail]>
>> To: "[e-mail]" <[e-mail]>
>> Subject: Re: [hybi] I-D Action:
>>         draft-ietf-hybi-permessage-compression-07.txt
>> Message-ID:
>>         <
>> [e-mail]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Reorganization, rephrasing, grammar correction.
>>
>> I'm happy if someone could take a look.
>>
>> Takeshi
>>
>>