- From: Jari Arkko <jari.arkko@piuha.net>
- Date: Thu, 19 Dec 2013 16:47:58 +0000
- To: Meral Shirazipour <meral.shirazipour@ericsson.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, General Area Review Team <gen-art@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Meral: thank you for your detailed review. You have done many reviews on this document set. Very much appreciated! I have a couple of comments below on the discussion, not commenting on this already agreed: > Actually going back to my comment : > " -Perhaps in part 1 give a suggestion on how to use/read these documents (RFCs). Could any of them be skipped at first for a simple implementation? > I think it is worthwhile spending minimum 2-3 pages to summarize the various documents (Parts) and suggest how to use them best. > " I agree that we should not change the structure of the documents at this stage. As I said in the other mail, I think a list of other documents and their primary use might have been a useful thing to do. >>> Not sure if "occasionally other common port traffic" means port 443? >>> ... >> >> Nope (at least that's my understanding). > > So it is other ports than 80/443? In this case, you may want to add 443 to the text. I think the situation is that we have multiple such ports… not sure mentioning the specific ones is necessary. >> >>> -[Page 16], would it be ok to use MAY? If so it would be clearer to use >>> MAY. : "A recipient MAY..." >>> >>> " >>> A recipient can assume that a >>> message with a higher minor version, when sent to a recipient that >>> has not yet indicated support for that higher version, is >>> sufficiently backwards-compatible to be safely processed by any >>> implementation of the same major version. >>> " >> >> Exactly how is that clearer? > > Please refer to http://tools.ietf.org/html/rfc2119 for extra significance. I think "MAY" would be my choice, but I understand the authors if they have a reason to try to stay with language and requirements that existing documents and implementations have used. >> >>> -[Page 17], Section 2.7.1 first line: "...for the purpose of minting >>> identifiers". >>> >>> suggestion: if another word than "minting" (e.g. generating, creating), >>> could be used it would be easier to read that section. >>> >>> (also used in section 2.7.2) >> >> I believe the term "minting" is very commonly used. > > I am not the best judge either (but I had to google it). I think this term is occasionally used, probably ok. >>> >>> Also the term "authoritative" is introduced and should be defined in this >>> context. >>> >>> " >>> If the server responds to that request with a non-interim >>> HTTP response message, as described in Section 6 of [Part2], then >>> that response is considered an authoritative answer to the client's >>> request. >>> " >> >> As defined in Part2, Section 6; that is, a status code other that 1xx. > > "authoritative" means coming from origin server? Was there a response, Julian? Jari
Received on Thursday, 19 December 2013 18:46:10 UTC