Re: [hybi] List of (mostly) editorial changes for draft-01

[Greg Wilkins <[e-mail]>]

On 3 September 2010 06:06, John Tamplin <[e-mail]> wrote:
> Leaving out the suggestions I agree completely with.
> On Thu, Sep 2, 2010 at 3:00 PM, Patrick McManus <[e-mail]>

>>  * Change the paragraph that begins "a sender MAY arbitrarily fragment a
>>
>> single message (which allows generation of dynamic content without
>> having to buffer the data in order to count it)." to read more simply "A
>> sender MAY create fragments of any size for non control messages." If we
>> need to explain why fragments are important, which I don't think we need
>> to do, that can live outside of normative section 4.

Fragments should probably be non-zero size, else we can get silly
infinite fragmentation.

>>
>> As drafted a ping and pong are meant to be paired together via their
>> content.. but the pong is allowed to truncate the content but isn't
>> given any mechanism to indicate that it has done so.. in light of that
>> how can the pinger determine if there is a match? If those truncated
>> bytes aren't relevant to the match, why did it send them in the first
>> place? My answer to that is to disallow truncation but limit the message
>> size to the tiny 125 byte frame size. If people want to argue for a
>> larger but still reasonable constant I don't have a problem with that.
>> Furthermore the draft made responding to the ping optional (SHOULD
>> level) which really makes it kind of useless as a keep-alive.. so I
>> changed that to MUST respond, but SHOULD do it soonish. (see text).
>
> The idea was that we require a minimum size for truncation, which would be
> sufficient to include an id and/or timestamp.  I would be fine with your
> suggestion as well.

I'm +1 on limiting ping/pong to a single tiny frame is a good idea.

However there was a use-case of sending a large ping to determine the
mtu of a path.  I think it would be great to be able to discover mtu,
but I'm not sure that sending a big ping is a good way of doing that.
So if we go with a tiny frame ping/pong, then we need to capture the
mtu use-case elsewhere.


>> We've been calling them control frames, not control messages, so I
>> assume that means they shouldn't be fragmented and I made that a
>> requirement. The alternative is to try and consistently call them
>> control messages. Personally, I don't see a reason to let them be
>> fragmented into multiple frames.
>
> I agree with the general principle of not fragmenting control messages (and
> it also solves the problem of interjecting control messages in the middle of
> a fragmented message, since you don't have to keep a stack of "open"
> messages).  However, I worry if later on we will want to have a control
> message that may need to be larger, in which case not being able to fragment
> it may cause other problems.

There are op-codes available to be define for large messages that are
not going to be directed at the existing text API. These should be
sufficient for future large non data messages.




cheers