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

[Dario Crivelli <[e-mail]>]

Hi Takeshi,


Regarding the observations I expressed about version 05 of the draft, I
confirm that the new text, along with your answers by email, do clarify my
doubts.

In the new version, I found just a few unclear points.

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.

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

On the other hand, I think it is obvious to all of us that a PMCE should
only operate on the message payload 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.
I'm not sure if the current specification conveys this idea.

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.


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