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

["Shelby Moore" <[e-mail]>]

> On Fri, Aug 27, 2010 at 4:32 PM, Shelby Moore <[e-mail]> 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.


I haven't see one concern other than the last message between Jamie and I,
for which I am still awaiting his reply to my challenge asking for any
example of his concern. And I understand that wasn't a major or blocking
concern of his. It seemed to me that Jamie was in support of non-conflated
layers, unless there was an overriding reason to conflate them.

Can you provide any link that has expressed any concern about my proposal
to not conflate the fragmentation framing and the message content layers?

Seems you could easily substantiate your statement if it is truely "large"
as you assert.  I think it is not only not "large", it is non-existent. So
I am little bit dismayed by this part of your reply.  What you wrote below
is warmly received.

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


That was very polite.  I thought my anti-conflation argument was
understood, but then I saw it needed more explanation.

Mainly I didn't want John replying to me, because he and I will get mired
in pedantic debate that has no bearing to the overall main point.  I am
interested to have discussions with anyone who is willing to make a best
effort to be efficient and to the (non-pedantic but overall) point.  I
enjoyed very much the discussion with Jamie, he was able to stay on the
main points efficiently. I have felt useful in helping to explain some
issues about fragmentation to Brian S. I have replied to Ray Field
asserting that SSH is not visible either, and got no reply on his
concerns.

I never said do not reply to my emails, I said do not copy me on the
reply, just in case I had unsubscribed, but yes it is fair to say that I
removed that footer from my messages and have been subscribed for the past
24 hours or so.

I have no desire to force anything on anyone.  I just want to know the
legitimate reasons for design choices. I am engineer, and I accept the
best design as the winner, I could careless if it was my design or not.  I
want the users of the world to win, I want Google to have a great protocol
to use, I want to use a great protocol.


>
>
>> > On Fri, Aug 27, 2010 at 2:02 PM, Scott Ferguson <[e-mail]>
>> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/hybi
>> >>
>> > _______________________________________________
>> > hybi mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/hybi
>> >
>>
>>
>