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

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 1 Apr 2013 23:41:05 +0900

Hi Dario,

Thanks for review.

On Fri, Mar 29, 2013 at 1:41 AM, Dario Crivelli <
[email-masked]> 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 <[email-masked]>
>> To: "[email-masked]" <[email-masked]>
>> Subject: Re: [hybi] I-D Action:
>>         draft-ietf-hybi-permessage-compression-07.txt
>> Message-ID:
>>         <
>> [email-masked]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Reorganization, rephrasing, grammar correction.
>>
>> I'm happy if someone could take a look.
>>
>> Takeshi
>>
>>

---

From: Dario Crivelli <[email-masked]>
Date: Thu, 4 Apr 2013 17:56:14 +0200

Hi Takeshi,

>From my viewpoint, the notes added in draft 08 make things clearer.
I will try to expand on some points of the previous email that don't have a
clear way out.
Then I will add other notes on the new draft 08 in the proper thread.

> Yes. Except for fragmentation change.

Consider that conflicts due to fragmentation only arise with extensions
that are supposed to be applied before the PMCE.
As the PMCE only operates on the payload, the incompatibility with any
previous extension operating on the frames, in my opinion, should be in
some way implicit (see below).

> Hmm, ... what kind of thing do you think we should say?

I'm not able to propose any solution, because there is nothing to lean upon.
However, I think that your reformulation of 5.1 and 5.2 in draft 08, where
you explicitly refer to extension chaining, is more prone to mutual
compatibility.

The job would be easier if RFC 6455 had put some more restrictions.
For instance, a statement that the encoding of a message is a two-phase
process, where:
- the first phase produces the message payload and its properties (in terms
of opcode and reserved bits, due to be set in the first frame);
- the second phase produces the frames, with any additional frame-level
opcodes and reserved bits (along with possible extension data and custom
control frames).
This would provide "inputs" and "outputs" for the extensions to operate on,
and also basic constraints on the chaining of extensions.

Do you think that imposing a similar restriction would cause possible
useful extensions to be ruled out?
By the way, I admit that I haven't managed to read the sibling proposal for
the Multiplexing extension yet, so maybe this restriction is already
unsuitable for that one.

>
>
>> By the way, in paragraph 4 it is said that an extension can be "applied
>> to output of" another extension;

Do you think that expanding RFC 6455, in order to clarify how the extension
should be allowed to operate, would still be possible?
In fact, anything stated regarding extensions should have no impact on the
protocol itself;
moreover, since no extension has been registered yet, making changes on the
matter now would pose no cross-compatibility issues.
But I'm not familiar with the specification process and I acknowledge that
this may be unfeasible.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 25 Apr 2013 19:27:01 +0900

On Fri, Apr 5, 2013 at 12:56 AM, Dario Crivelli <
[email-masked]> wrote:

> I will try to expand on some points of the previous email that don't have
> a clear way out.

Right.

> some way implicit (see below).

Yes. My rephrasing using newly defined terms clarifies that more.

> - the first phase produces the message payload and its properties (in
> terms of opcode and reserved bits, due to be set in the first frame);
> This would provide "inputs" and "outputs" for the extensions to operate
> on, and also basic constraints on the chaining of extensions.
>

I'm basically not concerned much with having such an input/output interface
between extensions. It has expressive power high enough.

Old deflate-stream idea needed replacing the second phase but it's now
deprecated.

>  By the way, I admit that I haven't managed to read the sibling proposal
> for the Multiplexing extension yet, so maybe this restriction is already
> unsuitable for that one.
>

Old one was. The latest one generates sequence of messages, not frames. So,
no problem.

> Do you think that expanding RFC 6455, in order to clarify how the
> extension should be allowed to operate, would still be possible?
> moreover, since no extension has been registered yet, making changes on
> the matter now would pose no cross-compatibility issues.
Useful, but... needs much work. It would bring long discussion imaging
various possible extensions. I prefer doing that later.