Re: Comments on the HTTPbis draft, v20

On 2012-09-05 19:13, Adrian Custer wrote:
> Hello everyone,

Hi there!

Comments to *some* of your feedback inline.


> This mail contains some initial editorial comments, questions, and
> recommendations for the httpbis draft
> (http://tools.ietf.org/wg/httpbis/), version 20.
>
> This work arose from a desire to develop a set of conformance tests for
> our web services establishing them as HTTP/1.1 conformant 'origin
> servers.' The analysis was derived from ignoring the bulk of the
> standard and focusing only on the formal injunctions, the sentences with
> the words 'MUST' or 'SHOULD,' with a focus on those affecting origin
> servers.
>
> While I had hoped to go through the whole document, I have stopped at
> section 3.3 of part 1. The review of the remaining injunctions will
> proceed in much the same way as for those presented here, asking similar
> questions of each one: is the target clearly identified, is the target
> one in the list given in section 2.6, is the injunction clear, if the
> injunction uses "SHOULD" is the conditionality of when an implementation
> can avoid the injunction clear, do we understand the consequences of
> violating the injunction, and so on. So the authors and editors, if they
> find the review worthwhile, should be able to make their own progress on
> the rest of the document.
>
>
>
>
> In reading your draft, two central questions arose that might
> fundamentally alter this analysis depending on your response.
>
> First, are 'targets' intended to be the only entities enjoined by the
> requirements of your standard?
>
> These are introduced, in section 2.6 in part 1 and in section 1.1 of
> part 2, apparently to define the entities for which rules will be made.
> However, the rules have not all been written to explicitly constrain
> instances of those targets. The formal adoption of a constrained set of
> elements would be very useful for readers of your standard, however,
> first, the list will probably need to be updated after formal review of
> all the injunctions and, second, the rules will need to be rewritten to
> focus explicitly on these targets only.

I have trouble understanding what you're asking for here.

> Second, are the requirements (aka 'injunctions' or 'rules'), that is the
> sentences with the capitalized 'MUST' and 'SHOULD,' intended to be the
> only source of normative text or are they merely intended to complement
> and stress certain aspects of the text?

The latter.

> ...
> * Could the lower case 'must' in the 'Copyright section' be changed to
> some other phrasing so as to keep that word for formal injunctions?
> ...

No, but you're welcome to argue this with the IETF Trust :-)

> ...
> * Use of angle brackets around syntax elements
>
> The current text does not use angle brackets to isolate and label
> protocol elements as against natural language ideas within the text
> writeup but it would be useful to distinguish the two. For example,
> 'HTTP message' should refer to the byte stream exchanged over a
> connection and '<HTTP-message>' to the syntax definition to which the
> byte stream must conform. Making the distinction explicit would clarify
> section 3 of part 1.
> ...

We discussed this in the past and we felt it would make the text harder 
to read.

> ...
> 2.6
>
>     In addition to the prose requirements placed upon them, senders MUST
>     NOT generate protocol elements that do not match the grammar defined
>     by the ABNF rules for those protocol elements that are applicable to
>     the sender's role.
>
> This is great as one of the initial, core requirements and, therefore,
> should not be buried here nor repeated in other parts (e.g. sec 1.1,
> part 2) but be a highly visible requirement of the standard. However, it
> could also be written more clearly.
>
> The first clause is superfluous since this is merely one more 'prose
> requirement' is it not? Also, 'prose requirement' seems to be trying to
> distinguish from other kinds of requirements but my understanding is
> that the only requirements are sentences with "MUST" or "SHOULD".

No, that is not true.

> ...
>     If a received protocol element is processed, the
>     recipient MUST be able to parse any value that would match the ABNF
>     rules for that protocol element, excluding only those rules not
>     applicable to the recipient's role.
>
> The implications of this requirement are unclear. What does 'is
> processed' imply? Are all messages sent to an origin server 'processed'
> or only some? What does 'able to parse' really imply?

"able to parse" means "must not fail to parse".

 > ...
> 2.7
>
>     When an implementation receives an
>     unrecognized header field, the recipient MUST ignore that header
>     field for local processing regardless of the message's HTTP version.
>
> Are any header fields required to be 'recognized'? If so, where is this

No.

> requirement stated? Are all implementations expected to 'not ignore' all
> of the headers defined in the HTTPbis spec?

It depends, and should be clear from the description of the header field.

> Note that 'implementation' is not in the list of targets of section 2.6:
> either it should be added to the list or the text modified.

Or we could invoke "common sense" :-).

>     An HTTP server SHOULD send a response version equal to the highest
>     version to which the server is conformant and whose major version is
>     less than or equal to the one received in the request.
>
> This would be better phrased as sending a 'response message whose
> <http-version> is ...'

I disagree that this is better :-)

> Under what circumstances is this not expected of HTTP/1.1 servers? The
> SHOULD allows for exceptions so it is useful to state the conditions
> where violating this rule is allowed.

Agreed!

>     An HTTP
>     server MUST NOT send a version to which it is not conformant.
>
> Again the phrasing could be clearer since servers send *messages* not
> "versions."

Is there *any* risk not understanding this?

> ..

I'll stop here due to time constraints; thanks a lot for the feedback; 
we will look into the details.

Best regards, Julian

Received on Wednesday, 5 September 2012 18:34:53 UTC