I've updated the pull request. You can see the changes there. Note that the reason I'm pushing back hard on text additions is that it's hard to ensure that I've correctly maintained the intent of text that has already been extensively reviewed. Deletions are easier, but only slightly. If you feel strongly about anything I've not acted on, feel free to raise it. On 21 January 2015 at 09:36, Elwyn Davies <elwynd@xxxxxxxxxxxxxx> wrote: > It's the WG's choice to limit transports to TCP : so be it. I'd have liked > to allow alternatives such as SCTP but that is a personal view. The only reason we did so is that no one offered to do the work. > How about adding "subject to limited constraints" to the Section 5 bullet. The statement is still correct without it. > I have done a bit of homework on this including having a look at > draft-pironti-tls-length-hiding-01, > so I hope I understand this a little better now. Practically, I think it > would be helpful to move the last paragraph of s6.1 and combine it with the > second para that introduces the idea of padding, making the security > implications more upfront. I think I am correct in saying that padding > would be pointless if not using TLS: I think it would be worth saying this > in s6.1. Sounds reasonable. > I think an (informative) reference to draft-pironti-tls-length-hiding-01 in > s10.7 would be useful - I think it covers the 'redundant padding could be > counterproductive' story in the 2nd sentence and also the statements in the > last para of s10.7. I think that I would, if it weren't for the relative levels involved here. The idea here is to include a clear signal that padding isn't necessarily easy and then leave it to implementers to learn that this warning was perhaps a little strong. Better that than a false sense of security. >> I don't think this is a problem. Most proposals that have been >> floated use a reciprocal SETTINGS frame to signal that the value was >> understood. The only failure mode there occurs when there is a >> collision between two extensions that results in two conflicting views >> of the setting semantics. Of course, that is equally possible with a >> rejection-based scheme. > > Sorry, but I don't understand your logic here. Let me try again: > > If (say) the client asks for a SETTINGS value from some future extension > that the server doesn't understand, my interpretation is that the server > will ignore the value it doesn't understand while doing the ones that it > does understand and say 'ACK' to the client. I assume that the client is > then entitled to believe that the server has interpreted its requested > SETTINGS as expected and the client can do whatever the extension was > intended to allow. Depending on what the ignored SETTINGS are, this may > have bad consequences during later operations. > > Accordingly, I think that the SETTINGS extension needs some way to tell the > requesting endpoint that the responding endpoint couldn't action (part of) > its requests. The requester can then act accordingly, terminating the > session or avoiding actions that exploit whatever setting couldn't be > actioned. Let me try again. The ACK only provides an indication that the settings that were understood were acted upon. It doesn't provide proof-positive that an extension was understood. Another mechanism is required for that. One potential solution is to include a value for the same setting in a separate SETTINGS frame. >>> s3.5, paras 2-5: It would be worth explaining that what is being done >>> here >>> is to send what would be a method request for the PRI method which will >>> not >>> be recognized by well-implemented HTTP/1.x servers. The PRI method is >>> then >>> reserved for HTTP/1.1 so that it can't be accidentally implemented later >>> (see Section 11.6). >> >> We've discussed providing explanatory text of this nature in the >> working group on a few occasions, but avoided it. In this case, the >> main beneficiaries of that information are people who aren't reading >> and implementing this specification, so we decided against more >> verbiage to that effect. > > Well.. with my gen-art hat firmly in place, part of the object of RFCs is > that they shouldn't be totally opaque to those who are reading them, even > those who aren't actually experts implementing the protocol. My suggestion > for an explanation would help those.. I didn't immediately twig why the > string was structured as it is. The right place for this discussion is the working group list. If you feel strongly enough. I'm trying very hard to avoid (re)opening issues. > <<snip>> >>> >>> s5.1, next to last para; s5.5, para 3, s6.2, END_HEADERS, para 2: >>> s5.1 says: >>> OLD: >>> Frame of unknown types are ignored. [...] >> I have little concern that the feature >> will be accidentally missed. > > Perhaps not but I spent some time worrying about the inconsistency so other > may.. > can we compromise on: > NEW: > Frames of unknown types are ignored except when they occur in CONTINUATION > frame sequences (see Sections 5.5, 6.2 and 6.6). My inclination is to remove the sentence entirely rather than fix it. >>> s5.1.1, last para/s3.4, last para, s9.1, para 3: Having to open a new >>> connection when stream ids run out interacts with the point made in s3.4 >>> that there is no guarantee that the new connection will support HTTP/2. >>> It >>> might be worth pointing this out in s5.1.1 and s9.1 - it means the client >>> has to be able to switch back to HTTP/1.1 in the very rare case that this >>> happens. Thought: Would it be useful for a server to have a SETTINGS flag >>> that guarantees that it would do HTTP/2 on all subsequent connections? >> >> Yes, and the fallback isn't necessarily pretty. At least not for >> performance. I think that the view is that this is a low risk >> scenario and not worthy of special attention. > > Hmm.. On the other hand, in the rare case that it does happen it might bite > the client nastily if not catered for. I think it is worth a short sentence > in s5.1.1 at least. If I were to do anything, I'd have thought that Sec3 was more appropriate, but I couldn't see anywhere there. One virtue of HTTP is that implementations are generally stateless. That extends to the transport/protocol mappings. This error doesn't arise because maintaining state about whether a server previously supported X is actually harder than just running the same logic every time. With ALPN that's free. >>> s6.2, END_STREAM flag, 2nd para: s/A HEADERS frame carries/A HEADERS >>> frame >>> can carry/ >> >> It always carries the flag, it is whether it is set that matters. > > In fact, isn't the first sentence of s6.2, para 2 redundant? The previous > para just said it signals stream end. I think you can delete it completely. I think that I got the text in question. Yeah.