Re: [hybi] a working draft, not a final draft

On Fri, Aug 27, 2010 at 4:32 PM, Shelby Moore <shelby@coolpage.com> wrote:

> > As Editor, I will happily produce a draft based on John's earlier VII
> > proposal, based on 7/16/63 aka 1/2/8. Give me some time, the current
> draft
> > was very procedural and I would like to take the opportunity to re-write
> > it
> > in the format that we've been discussing on the list. I will spend time
> > this
> > weekend and hope to have something to send out early next week.
>
>
> See below please Ian.
>
> Note 9 people viewed my proposal so far, perhaps only 4 or 5 of them
> viewed it for any length of time to be serious.  18 people viewed John's
> proposal (which is already well known I guess).
>
> I think as an editor, your job is to respect the minority too, especially
> given the conflict of interest with John and you and Robert Peon all
> working for the same company?
>
>
>
Your proposal reflects a position that I think many people have already
expressed a large amount of concern over, in various threads. As for any
conflict of interest, I was actually asked by the chairs earlier to start
preparing something like what I proposed in my previous email.

Also, I don't know how to ask this in a manner that doesn't seem impolite so
please don't take this the wrong way: Previously you said you were
unsubscribing from the list and not to add you to emails, is it safe to say
we can disregard that at this point?

> > On Fri, Aug 27, 2010 at 2:02 PM, Scott Ferguson <ferg@caucho.com> wrote:
> >
> >> In the interest of moving the discussion forward, I have two proposals,
> >> which can be considered independently:
> >>
> >> a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a final
> >> draft
> >>
> >> b) Simplify the extension question to "does my favorite extension model
> >> work inside the working draft", not "which extension model is best."
> >>
> >> I'm not suggesting a consensus call on the final encoding, just
> >> suggesting
> >> that we take the good progress we've made so far and use it as a working
> >> draft. Not shutting down the encoding questions, but letting us pick a
> >> temporary working model so we can move forward.
> >>
> >> The objections I've seen to John's encoding have been around optimality,
> >> which we can put off temporarily.
>
>
> Agreed I guess. Although John's proposal is fundamentally different than
> mine in terms of the orthogonality of framing and messaging (because
> messaging opcodes in mine will never go in frame header if the frames are
> fragments):
>
>
> https://docs0.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&authkey=CLOirMAE#
>
> The way extensions may work should be similar, unless they are concerned
> with the framing orthogonality.
>
> The only other difference I can see between John's proposal and mine (my
> RSV can defined same as his if we want when fragmentation has been
> negotiated, even I can make mine 7/16/63 if we want), is that he wastes 1
> 'MORE' bit in every frame.  John's proposal will still need the message
> body for first frame to contain the defragmented message body length, same
> as mine, because the 'MORE' bit doesn't tell you the total message body
> size (the size in his frame header is the size of the frame, not the
> defragmented message body length).  I think the 'MORE' bit has no use.
> The reciever who will defragment, must know the message body length any
> way or parse an EOM marker.  Why does John have both 'MORE' and
> continuation bit in the payload?  The framing layer doesn't need to know
> if it is continuation, only the messaging layer does.
>
>
> >> We can come back to that discussion,
> >> but
> >> let's not get stuck here.
> >>
> >> For (b), the extension question, I'd suggest a modest change to John's
> >> proposal by removing all notion of control/extension opcodes, and
> >> restoring
> >> the ping/pong/close to the base opcodes (again, this is for
> >> draft/working
> >> purposes only), and leaving all reserved bits and other opcodes
> >> reserved. In
> >> other words, remove all extension concepts and leave everything possible
> >> reserved.
> >>
> >> Then, the extension question simplifies to: can the extension model work
> >> with this frame encoding as a foundation? Assume the extension model can
> >> use
> >> any reserved bits or reserved opcodes it wants to.
> >>
> >> -- Scott
> >>
> >>
> >> _______________________________________________
> >> hybi mailing list
> >> hybi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/hybi
> >>
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> >
>
>