Subject: Re: [hybi] Comments on draft-ietf-hybi-permessage-compression-05

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 1 Apr 2013 22:11:42 +0900

Hi,

On Sat, Mar 23, 2013 at 4:23 PM, SM <[email-masked]> wrote:

> Hi Takeshi,
>
>>
>> Sorry I couldn't get what you mean.
>>
>
> What I meant was not to get into all the details of how to implement.  It
> is better in my opinion to explain what is being sent.  Please let me know
> if I did not explain it well.
>
>
OK. But since the algorithm itself is defined by showing the steps, some of
examples demonstrating it would have to be step by step example and I think
are still useful.

I think now the examples of permessage-deflate except the first one are not
getting into implementation details:
- endpoint does X
- the result will be frame Y, frame ...
- Z in Y means blah blah, W in Y means blah blah

>  Which part of the sentence is bad for the RFC Editor?
>>
>
> I don't really know how to explain this.  I would say that the sentence
> looks more like pseudo code instead of one written in English.

I tried to eliminate such expressions, again from the examples section.

>  Could you please point a sentence which is considered to be making
>> liberal use of the key worlds? I tried to remove inappropriate use but
>> couldn't find so many.
>>
>
> I'll comment using an example from draft-ietf-hybi-permessage-**
> compression-07:
>
>   'A server MAY attach the "c2s_no_context_takeover" extension parameter
>    to disallow the client to use the LZ77 sliding window used to build
>    frames for the last message the client sent to build frames for the
>    next message to send.  The "c2s_no_context_takeover" extension
>    parameter has no value.  Clients SHOULD be able to accept the
>    "c2s_no_context_takeover" parameter.  A client that received this
>    parameter MUST reset its LZ77 sliding window for sending to empty for
>    each message.'
>
> There are three RFC 2119 key words in the above, i.e. MAY, SHOULD, MUST.
>  The client "SHOULD be able to accept" is an assumption.

Hmm. I meant it's recommended to make clients be able to accept the
c2s_no_context_takeover.

I'll changed it to use RECOMMENDED and separated them from requirement
paragraph.

>  The "MUST reset" is what the client must do.

Yes

>  I could write it in terms of what "c2s_no_context_takeover" means and
> what the client must do when it receives the parameter.

OK

Thanks

---

From: SM <[email-masked]>
Date: Mon, 08 Apr 2013 14:11:44 -0700

Hi Takeshi,
At 06:11 01-04-2013, Takeshi Yoshino wrote:
>I think now the examples of permessage-deflate except the first one 
>are not getting into implementation details:
>- endpoint does X

Ok.

>There are three RFC 2119 key words in the above, i.e. MAY, SHOULD, 
>MUST.  The client "SHOULD be able to accept" is an assumption.
>
>

In that case it could be made straight-forward by, for example, saying:

   Clients SHOULD accept the "c2s_no_context_takeover" parameter.

>I'll changed it to use RECOMMENDED and separated them from 
>requirement paragraph.

You could use that instead.

Regards,
-sm

---

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

>   Clients SHOULD accept the "c2s_no_context_takeover" parameter.
I see. Thanks