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

[Peter Thorson <[e-mail]>]

On Jun 13, 2013, at 12:23 , Takeshi Yoshino <[e-mail]> wrote:

> The current draft reads:
> 
> " It is RECOMMENDED that clients implement the
>    "c2s_no_context_takeover" parameter."
> 
> It's not "MUST implement" .. so there might be client which won't, and then a server has no chance to adapt it's response to the client and maximize likelihood of connection success given it ideally wants to activate "c2s_no_context_takeover".
> 
> Oh, this is a bug. This should be MUST.

+1

>> Yes. Order means preference. The server may choose any even if it 
>> supports all of them.
>> 
>> Do you think we need any text to make it clear?
> 
> I think it would clarify things by adding text like
> 
> """
> A server MAY choose any PMCE offered by the client and supported by the server.
> The order of PMCE offered by the client designates preference by the client and a server SHOULD accept the first offer in the list (by order) that it supports.
> """
> 
> This IMHO makes sense and brings the abstract description in line with the text in "5.1. Negotiation Examples".


Technically RFC6455 explicitly states that extensions are offered in order of preference, but I agree that there should be some text here (beyond the hints in the examples) that either references that or just reminds implementers that this is the case. 


Just to confirm, am I correct in assuming the following operations shouldn't cause problems:
1. Either endpoint may unilaterally send messages compressed with a smaller window size than the (implicit or explicit) negotiated maximum window size.
2. Either endpoint may unilaterally reset its own context for outgoing messages without informing the peer that it is doing so.