- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 01 Aug 2013 09:12:11 +0200
- To: Eliot Lear <lear@cisco.com>
- CC: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On 2013-07-31 19:37, Eliot Lear wrote: > I have two problems with the above and one overarching concern that > really needs to be addressed. First, the above text is taken out of > context. Flow control windows MUST always be obeyed by the sender. It > says so right in the previous paragraph. > > Second, if you don't agree with the above, changing "MAY" to "can" > doesn't get around the fact that you're giving advice to implementers on > the use of flow control, and yet that advice would be wrong because it > could be ignored by senders. This is, in other words, a distinction > without a difference. > > And this brings me to my general concern. Stop running away from > normative language. This WG is writing a specification that is intended > to be very widely deployed. It is intended to supplant the most widely > deployed application protocol ever, and therefore interoperability and > deterministic behavior is important. So is the use of standard > well-known normative terms. They are carefully defined with specific > meanings that are well known that most programmers understand. They are > *so* well known that many standards organizations have adopted them. > > Lastly, these words are contained in a voluntary standard. If you don't > follow them, the IETF believes that you may have an interoperability, > performance, or security problem, and in some cases you might cause > problems for others. The problem that I have with this "MAY" is that it states something obvious; we have a flow control feature, and a party in the data flow can invoke it. Why is there a "MAY" here? Best regards, Julian
Received on Thursday, 1 August 2013 07:12:43 UTC