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

[Dario Crivelli <[e-mail]>]

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.



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

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


>
>
>>
>> I'm not sure if the current specification conveys this idea.
>>
>>
> 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;
>> 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
>

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.



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