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

[John Tamplin <[e-mail]>]

Leaving out the suggestions I agree completely with.

On Thu, Sep 2, 2010 at 3:00 PM, Patrick McManus <[e-mail]>wrote:

> Section 4.1 - normative Data Framing Overview
>
>  * strike the sentence "The base framing protocol is deliberately kept
> simple so that simple implementations may ignore advanced features."
> There is no definition of simple implementations, no definition of
> advanced features, and no definition of what ignore might mean in this
> context. What is an implementor to do with it? :)..  I personally don't
> think we need the text at all, but if we want it move it to a
> non-normative section.
>

Maybe there needs to be a separate document with the rationale, or perhaps
they can be kept inline in the draft with the understanding that they will
not be present in the final version, but this and other statements were
intended to make clear the rationale for the choice and to alleviate
concerns held by those wanting a simple protocol and those wanting to make
sure their more complex use cases would be covered.


>  * 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.
>

This is another case like above, giving the rationale to head-off
objections.  It can go inline annotated as such, a separate non-normative
section collecting all the rationale bits, or a separate document.


>  * Change the paragraph "A receiver MUST be prepared to accept
> arbitrarily fragmented messages, even if the sender sent the message in
> a single frame." to the more direct "A receiver MUST support receipt of
> fragmented messages.". .. I assume the text about "sender sent .. in
> single frame" is referring to intermediaries, but it can't really happen
> like that - the intermediary is a sender too. To express the concept we
> would have to define something like origin-server/user-agent which are
> subsets of senders.. but I really don't see why this paragraph needs the
> concept at all.
>

As mentioned in an earlier reply on the list, it was to make clear that even
if someone wrote both the receiver and the sender endpoints, the receiver
must support receiving fragments even if the sender didn't send them.  If it
is sufficiently clear that requiring a receiver to support fragmentation
means even if the sending endpoint (as differentiated from an intermediary)
didn't fragment the message, then I am fine with that.


> 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.


> 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.


> With that being said - this is the proposed replacement for section 4.4:
>

With the above caveats, I am fine with your replacement text.


> Section 4.7 Extensibility
>
> With respect to section 4 framing there isn't a lot to say about
> extensibility. I replaced the existing section 4.7 text with this:
>

Again, this section was primarily intended to alleviate fears that the base
protocol was not extensible enough to support some of the ideas that have
been discussed.

-- 
John A. Tamplin
Software Engineer (GWT), Google