Re: "MAY employ flow control", was: draft-ietf-httpbis-http2 feedback

The language is ambiguous. "Flow control" may refer to one side informing
its peer of the memory limits, or it may refer to obeying the memory limits
received from the peer, or both. It looks like the spec is talking about
the former, but all implementations need to support the latter.

Ideally the spec would be more clear about this distinction; it was
confusing to me earlier also, especially in discussing the disabling of
flow control (which is applicable only to the first meaning).

On Wed, Jul 31, 2013 at 5:10 PM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-07-31 16:46, Amos Jeffries wrote:
>
>> On 31/07/2013 9:34 p.m., Julian Reschke wrote:
>>
>>> Questions:
>>>
>>>  <snip>
>>
>>>
>>> 5.2.2
>>>
>>> "Deployments with constrained resources (for example, memory) MAY
>>> employ flow control to limit the amount of memory a peer can consume.
>>> Note, however, that this can lead to suboptimal use of available
>>> network resources if flow control is enabled without knowledge of the
>>> bandwidth-delay product (see [RFC1323])."
>>>
>>> s/MAY/can/
>>>
>>>
>> I took this as being intentionally normative language. One participant
>> MAY use the feature therefore all participante MUST implement support
>> just in case it happens. With "can" there is no normative requirement on
>> the other participants to implement anything regarding flow control,
>> which would lead to harm for the participant needing it.
>>
>
> If *that* is the concern it really needs to be addressed more clearly.
>
> (I had the impression that flow control support clearly is not optional).
>
> Best regards, Julian
>
>
>