Starting HTTP/2.0 for HTTP - Upgrade

while implementing the 06 draft we have discovered that
when starting HTTP/2.0 for http with the Upgrade mechanism
the client sends twice (according to Section 3.2)

the first time it in the HTTP2-Settings header field and the second

      GET /default.htm HTTP/1.1
      Host: server.example.com
      Connection: Upgrade, HTTP2-Settings
      Upgrade: HTTP/2.0
      HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload>


the second is after the reception of the 101 response

     Upon receiving the 101 response, the client sends a
    connection header (Section 3.5), which includes a SETTINGS frame.


Another thing that we think should be clarified during starting HTTP/2.0 
(common to both the scenario http and http2)
is related to the second to last paragraph of Section 3.5

    To avoid unnecessary latency, clients are permitted to send
    additional frames to the server immediately after sending the client
    connection header, without waiting to receive the server connection
    header.  It is important to note, however, that the server connection
    header SETTINGS frame might include parameters that necessarily alter
    how a client is expected to communicate with the server.  Upon
    receiving the SETTINGS frame, the client is expected to honor any
    parameters established.


in the paragraph it is not clear what happens (what should be the 
default behavior) if
the server alter how a client is expected to communicate with the server.
This ambiguity could lead to different server side implementations and 
then to
unexpected behaviors
It would be better to specif, to avoid vulnerability in server 
implementations, something like the following:
"if the client exceeds any imitations of the server before the SETTINGS 
is understood by the client,
the server SHOULD/MUST send GOAAWAY."
an alternative to this proposal is that the server SHOULD enforce the 
local SETTINGS.

best regards
Salvatore Loreto

www.sloreto.com