Re: [hybi] Ben Campbell's No Objection on draft-ietf-hybi-permessage-compression-24: (with COMMENT)

[Takeshi Yoshino <[e-mail]>]

Hi Ben,

Thank you for review. Replies inlined.


On Wed, Jul 8, 2015 at 7:38 AM, Ben Campbell <[e-mail]> wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-hybi-permessage-compression-24: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> *** Substantive Comments: ***
>
> -- I think Robert Spark's secdir comments concerning an intermediary
> changing the signaling of extensions deserves some thought.
>

Discussing with Robert at
https://mailarchive.ietf.org/arch/msg/hybi/Db9oaqh86_DsHpx_XE6xiZFUmU0


>
> -- section 5, several example paragraphs:
>
> It's odd to find normative language in example. I _think_ the actual
> normative text is all covered elsewhere--if so, it should be written
> descriptively here.
>

Replaced "MAY" with "may".


>
> -- section 5, paragraph 6: ""Agreed parameters" MUST represent..."
>
> That seems more a statement of fact than a normative statement.  If it's
> intentionally normative, the required condition is vague for a MUST.
>
>
This statement was added for clarification when we allowed listing multiple
offers and have the server choose and ack one from them. The point we'd
like to remark is that configurations that the client requested should be
echoed so that the client doesn't have to identify which request has been
accepted.

It's not requirement for implementors but for spec writers of
permessage-foobar in the future.

OK, I'll replace this with "must".


> -- 6.1, Numbered list entry "2", third bullet (and several similar
> assertions)
>
> Do I understand correctly that the PMCE needs to know if the next
> extension wants frames, in order to determine whether to build them? How
> would it know that?
>

It's about gluing implementation of PMCE and one of the next extension. If
the next extension expects a frame for its input, we need to build a frame
to match the interface. RFC 6455 didn't defined detailed interface between
extensions, so we cannot write negotiation algorithm that work well with
every extension (including the case where they cannot connect with each
other). All I could do is listing two basic and known interfaces and
explain how to glue PMCE with them.

- The _Send a WebSocket Message_ algorithm and _A WebSocket Message Has
Been Received_ are defined in it. So, I explained how to glue PMCE with
them.
- And mentioned another simplest case other extensions may adopt (expecting
a sequence WebSocket frames for input/output), too.


>
> -- 9:
>
> I’m surprised that there’s nothing here about intermediaries. For
> example, if an endpoint chooses not to compress because of the mentioned
> issue with encrypting compressed data, does it have to worry that some
> intermediary might choose to compress it anyway?
>

In the discussion with Robert, I'm proposing removal of the intermediaries
sections. So, the spec at least won't suggest change of permessage-deflate
any more.

I understand your concern, but telling the consideration about combination
of extensions should be basically sufficient as it's not limited to
endpoints but applies to intermediaries if any. We could add some
clarification texts.

But as the intermediaries sections are likely to be gone, I hesitate to
mention intermediaries here too because of the same reason as I replied to
Robert.


>
> -- 12.2, [CRIME]
>
> Seems like this may need to be normative. I’m not sure the reader can
> fully understand the security considerations without reading it.
>

Hmm, is it fine to put it in the normative section? For now, moved in the
latest version.


>
> ***Editorial Comments:***
>
> -- Section 3, first paragraph, last sentence:
>
> That seems true anytime a draft or RFC defines terms--what is special
> about these?
>
>
Oh, right... Yes, I just removed it.


> -- 3, third paragraph: "An extension in use next to extension"
>
> The construction "next to" usually connotes adjacency, not order. I
> suggest "The next extension in use" (without the "to").
>
>
I see. But how should I connect the revised phrase with "extension X"? The
next extension in use "of" extension X?


> -- 8, 2nd to last paragraph:
>
> While you cited the LZ77 bits earlier, it would be useful to repeat that
> citation here. This is where the information actually gets used.
>

Added!


>
> -- 8.2.3.6:
>
> It's odd to refer to anything done by a computer as "manual".
>

Just removed occurrences of "manually"