[hybi] Comments on draft-ietf-hybi-permessage-compression-05

[SM <[e-mail]>]

Hi Takeshi,

This is an individual comment on 
draft-ietf-hybi-permessage-compression-05.  I did not cover all the 
issues.  Sorry for not providing ample explanation.

In Section 1:

  "_This section is non-normative._"

This style is unusual for IETF Stream documents.  I suggest switching 
back to the usual style.

   "As well as other communication protocols, the WebSocket Protocol
    [RFC6455] can benefit from compression technology."

The sentence would benefit from a rewrite.  It could alternatively be dropped.

I suggest first specifying the framework and then go into the 
details.  I would look at the Introduction Section in terms of 
providing an introduction to the topic and after that a view of what 
to expect in the other sections so that there is a "logical" 
flow.  Sorry for not describing this in better terms.

In Section 3:

   'Extensions build based on this framework are collectively
    called "Per-message Compression Extensions".'

Where is there an explanation for the framework?

   'To request use of a Per-message Compression Extension, a client
    MUST include an element with its extension token in the
    "Sec-WebSocket-Extensions" header in its opening handshake.'

What is "element" and what is "extension token"?

   "A client MAY list multiple Per-message Compression Extensions
    with the same name to offer use of the same algorithm with
    different configurations."

Why is this a MAY?

   "The parameters MUST be derived from the parameters sent by the
    client and the server's capability."

What is the meaning of "the parameters must be derived"?

   'To reject use of a Per-message Compression Extension, a server MUST
    simply ignore the element in the "Sec-WebSocket-Extensions" header in
    the client's opening handshake.'

This is not clear.

   "If a client doesn't support the extension and its parameters replied
    from the server, the client MUST _Fail the WebSocket Connection_."

What is the meaning of "MUST _Fail"?

   "Otherwise, once _the WebSocket Connection is established_, both
    endpoints MUST use the algorithm described in Section 4 to exchange
    messages."

This comes out as IF requirement1 ELSE requirement2.

I suggest explaining how the protocol should work.  Error handling 
could be part of that.

In Section 4.1:

   "To send a compressed message, an endpoint MUST use the following
    algorithm."

I only need to know the format to use to send the compressed 
message.  I suggest looking at it from that angle instead of 
specifying an algorithm.

In Section 5.2.1:

   "The ABNF [RFC5234] for the value of this parameter is 1*DIGIT."

I suggest following the usual practices for ABNF (see existing RFCs 
for examples).

Each section seems like a standalone part of the draft.  In Section 5.3.2.1:

   "The first 2 octets are the WebSocket protocol's overhead (FIN=1,
    RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7)."

I suggest using ASCII art for illustration.

   "To send it after fragmentation, split the compressed payload and
    build frames for each of split data as well as fragmentation process
    done when the compression extension is not used."

I suggest avoiding the tutorial approach.  I would look at this as 
what goes on the wire.
In Section 6:

   "There are no security concerns for now."

This is going to flag this as an issue.  I suggest thinking about the 
security considerations.  There must be something which could go wrong.

The basic idea is there.  It is a matter of having text to explain 
that.  I suggest avoiding sentences like 'Then, a block containing 
"llo" follows.' as it will create more work for the RFC Editor.  The 
draft unfortunately has to be rewritten.  It is better not to make 
liberal use of RFC 2119 key words.  I suggest using them for 
interoperability.  RFC 6709 discusses about design considerations for 
extensions.  It could be used as guidance.  I suggest looking at some 
other RFCs discussing about extensions to get an idea of the possible 
styles and then choosing one.

Regards,
-sm