W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: [Gen-art] [httpbis] #523: Gen-ART Last Call review draft-ietf-httpbis-p1-messaging-25

From: Jari Arkko <jari.arkko@piuha.net>
Date: Thu, 19 Dec 2013 16:47:58 +0000
Cc: Julian Reschke <julian.reschke@gmx.de>, General Area Review Team <gen-art@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <01C6E699-296A-4C21-9D7A-4D51FB4516CA@piuha.net>
To: Meral Shirazipour <meral.shirazipour@ericsson.com>
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?

Received on Thursday, 19 December 2013 18:46:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:21 UTC