[hybi] a working draft, not a final draft

[Scott Ferguson]

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

[John Tamplin]

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a final
draft

Do you mean the VII proposal, or the one I just posted a link to?

Post by Scott Ferguson
b) Simplify the extension question to "does my favorite extension model work
inside the working draft", not "which extension model is best."

Agreed.

Post by Scott Ferguson
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.

The reason I still like having a separate Control opcode is that
presumably the control frames will be far less frequent than data
frames. If we moved them into the opcode, we would be eating up 2 of
the 8 available opcodes (since you would get Control back), and it
seems likely at some point we will have to define an extended opcode
which takes a byte or two out of the payload. It seems you would
rather the infrequent Control frames use the extra byte than the more
frequent data-bearing opcodes.

That said, I don't feel that strongly about it so if others think the
conceptual weight of having a control frame is not worth the benefit I
am fine with merging them back into the opcode.

[Scott Ferguson]

Post by John Tamplin

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a final
draft

Do you mean the VII proposal, or the one I just posted a link to?

Either. It's a working draft. The linked draft is good. For the purposes
of my suggestion, they're equivalent.

Post by John Tamplin

Post by Scott Ferguson
b) Simplify the extension question to "does my favorite extension model work
inside the working draft", not "which extension model is best."

Agreed.

Post by Scott Ferguson
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.

The reason I still like having a separate Control opcode is that
presumably the control frames will be far less frequent than data
frames. If we moved them into the opcode, we would be eating up 2 of
the 8 available opcodes (since you would get Control back), and it
seems likely at some point we will have to define an extended opcode
which takes a byte or two out of the payload. It seems you would
rather the infrequent Control frames use the extra byte than the more
frequent data-bearing opcodes.

That's an optimality question. For the purposes of my suggestion, I'm
proposing temporarily stripping out all concepts of extension for a base
working draft, so we can all look at the same minimal proposal. (People
are getting overwhelmed, including me.) After we have a bare-bones
working draft, we can work on optimizing it and making it extensible.
Basically simplicity of the base for one rough draft over all other
considerations.

Later, we can add back your control opcode model (assuming there's
consensus on the value, of course). But for temporary purposes of
producing a minimal, simple, simple draft, I'm suggesting stripping out
even that simple extension idea, and temporarily postponing
consideration of it until we have a minimal draft to work from.

Post by John Tamplin
That said, I don't feel that strongly about it so if others think the
conceptual weight of having a control frame is not worth the benefit I
am fine with merging them back into the opcode.

Yes, but this would just be a temporary postponement for discussion of
that proposal, not a final decision or a rejection of it.

-- Scott

[John Tamplin]

Later, we can add back your control opcode model (assuming there's consensus
on the value, of course). But for temporary purposes of producing a minimal,
simple, simple draft, I'm suggesting stripping out even that simple
extension idea, and temporarily postponing consideration of it until we have
a minimal draft to work from.

Ok, would you like me to change the document to reflect that?

[Scott Ferguson]

Post by John Tamplin

Later, we can add back your control opcode model (assuming there's consensus
on the value, of course). But for temporary purposes of producing a minimal,
simple, simple draft, I'm suggesting stripping out even that simple
extension idea, and temporarily postponing consideration of it until we have
a minimal draft to work from.

Ok, would you like me to change the document to reflect that?

I think that would be helpful so we can more easily evaluate various
proposals as changes to a minimal draft.

(I just noticed that also temporarily stripping out the 12-15 opcode
allocation for private use would be more minimal.)

Post by John Tamplin
One other issue I just remembered -- if we allow control frames to go
in the middle of a fragmented message, not having a control frame
means you have to define which opcodes are considered control opcodes.
If we don't allow that, then there is no issue but it may limit the
value of "ping" for example.

Right. I just think the control opcode proposal may be easier to
evaluate and keep track of if it looks something like:

"[tamplin.1] add control opcode and move ping/pong/close to control group

Why needed: a) ... b) In the current draft, if we allow control frames
to go in the middle of a fragmented message..."

-- Scott

[John Tamplin]

Post by Scott Ferguson

Post by John Tamplin
Ok, would you like me to change the document to reflect that?

I think that would be helpful so we can more easily evaluate various
proposals as changes to a minimal draft.
(I just noticed that also temporarily stripping out the 12-15 opcode
allocation for private use would be more minimal.)

Done.

Post by Scott Ferguson
Right. I just think the control opcode proposal may be easier to evaluate
"[tamplin.1] add control opcode and move ping/pong/close to control group
Why needed: a) ... b) In the current draft, if we allow control frames to go
in the middle of a fragmented message..."

I created an "Other Modifications" section in the document and moved it there.

[Shelby Moore]

Please wait an hour or so or maybe less. I am composing a competing draft
proposal. Will post it here.

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
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. 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
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

Here is my draft, which is much superior to John's:

WebSocket Framing Orthogonal to Messaging Proposal

https://docs.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&hl=en&authkey=CLOirMAE

Greg Wilkins will certainly find mine more favorable. As will anyone who
values correct orthogonal design of layers.

John I even linked to yours from mine.

Post by Shelby Moore
Please wait an hour or so or maybe less. I am composing a competing draft
proposal. Will post it here.

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
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. 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
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[John Tamplin]

Post by Scott Ferguson
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.

One other issue I just remembered -- if we allow control frames to go
in the middle of a fragmented message, not having a control frame
means you have to define which opcodes are considered control opcodes.
If we don't allow that, then there is no issue but it may limit the
value of "ping" for example.

[Ian Fette (イアンフェッティ)]

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.

-Ian

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
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. 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
https://www.ietf.org/mailman/listinfo/hybi

[Gabriel Montenegro]

Sounds good, looking forward. One request: could you use the 32-bit format used in the VII proposal, rather than the 16-bit format in the more recent proposals on googledocs? The former is more common in IETF docs.

Also, thanks to John and others for summarizing the discussions and producing crisper proposals so folks can actually follow.

From: hybi-***@ietf.org [mailto:hybi-***@ietf.org] On Behalf Of Ian Fette (????????)
Sent: Friday, August 27, 2010 4:03 PM
To: Scott Ferguson
Cc: ***@ietf.org
Subject: Re: [hybi] a working draft, not a final draft

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.

-Ian
On Fri, Aug 27, 2010 at 2:02 PM, Scott Ferguson <***@caucho.com<mailto:***@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. 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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

Post by Ian Fette (イアンフェッティ)
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?

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
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.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Ian Fette (イアンフェッティ)]

Post by Shelby Moore

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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?

Post by Shelby Moore

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two proposals,
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
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.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
was very procedural and I would like to take the opportunity to

re-write

Post by Ian Fette (イアンフェッティ)
it
in the format that we've been discussing on the list. I will spend

time

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two

proposals,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a

final

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft
b) Simplify the extension question to "does my favorite extension

model

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft. Not shutting down the encoding questions, but letting us pick

a

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
temporary working model so we can move forward.
The objections I've seen to John's encoding have been around

optimality,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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
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.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
reserved.
Then, the extension question simplifies to: can the extension model

work

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
with this frame encoding as a foundation? Assume the extension model

can

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
use
any reserved bits or reserved opcodes it wants to.
-- Scott
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Ian Fette (イアンフェッティ)]

Post by Shelby Moore

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
was very procedural and I would like to take the opportunity to

re-write

Post by Ian Fette (イアンフェッティ)
it
in the format that we've been discussing on the list. I will spend

time

Post by Ian Fette (イアンフェッティ)
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?

http://www.ietf.org/mail-archive/web/hybi/current/msg02747.html
http://www.ietf.org/mail-archive/web/hybi/current/msg02752.html

Note that I intend this as a response to your email about the "MORE" bit as
well. I previously made a similar argument for keeping track of state, e.g.
indicate that something is an initial frame in the first frame, and then you
can make do with a single bit rather than having separate start/continue/end
opcodes. However, Dave and others made a reasonable argument for wanting to
explicitly demarcate start/continue/end. While I don't want to try to speak
on Dave and Doug's behalf, as I read your proposal their argument seems like
it would apply to your proposal as well.

Post by Shelby Moore
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.

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two

proposals,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a

final

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft
b) Simplify the extension question to "does my favorite extension

model

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft. Not shutting down the encoding questions, but letting us pick

a

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
temporary working model so we can move forward.
The objections I've seen to John's encoding have been around

optimality,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

https://docs0.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&authkey=CLOirMAE#

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
reserved.
Then, the extension question simplifies to: can the extension model

work

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
with this frame encoding as a foundation? Assume the extension model

can

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
use
any reserved bits or reserved opcodes it wants to.
-- Scott
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

See below about Almost Better Than Useless 'MORE' bit and waste of 4 bits
in frame header...

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
As Editor, I will happily produce a draft based on John's earlier

VII

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
proposal, based on 7/16/63 aka 1/2/8. Give me some time, the

current

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
draft

Post by Ian Fette (イアンフェッティ)
was very procedural and I would like to take the opportunity to

re-write

Post by Ian Fette (イアンフェッティ)
it
in the format that we've been discussing on the list. I will spend

time

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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?

http://www.ietf.org/mail-archive/web/hybi/current/msg02747.html
http://www.ietf.org/mail-archive/web/hybi/current/msg02752.html
Note that I intend this as a response to your email about the "MORE" bit
as well. I previously made a similar argument for keeping track of state,
e.g. indicate that something is an initial frame in the first frame, and
then you can make do with a single bit rather than having separate
start/continue/end opcodes. However, Dave and others made a reasonable
argument for wanting to explicitly demarcate start/continue/end. While I
don't want to try to speak on Dave and Doug's behalf, as I read your
proposal their argument seems like it would apply to your proposal as
well.

The first link you provided is saying that we need decent error handling
(i.e. CRC), instead of the proposed bits.

The second links you provided above admits math processors have CRC
capabilities and thus is not trying to make a strong argument for the
Almost Better Than Nothing 'MORE' bit. And the second link was contested
by others including Roberto Peon who works at your company:

http://www.ietf.org/mail-archive/web/hybi/current/msg02795.html
http://www.ietf.org/mail-archive/web/hybi/current/msg02797.html

Apparently there were no followups.

The technical case for the 'MORE' bit is almost non-existent (as well the
continue bit is Almost Better Than Useless too).

Even without CRC error checking, that bit doesn't gain any redundancy that
you don't also get from multiplexing data that will sit on top of the
fragmentation.

If we are truely worried about TCP bit errors (and cosmic rays too), then
we should do a proper CRC error check, because the 'MORE' bit will do
nothing to stop bit errors in the message opcodes, content length, parsing
forks, etc. We can either require proper CRC error check, or we can
delegate it to the application.

Also if we are running on an encrypted TLS channel, then I assume the
decryption will detect such TCP bus bit errors?

Thus there has been no justification presented for conflating the
fragmentation and messaging protocols. I have explained well how to
unconflated them in my proposal. And I have explained how to give us a lot
more available bits in the frame header as a result:

https://docs0.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&authkey=CLOirMAE#

Also there has not yet been any followup to the technical point I made in
my prior reply on this thread, where I explained that the 4 bits allocated
to the opcode in the frame header are wasted on every fragment. This is
because John's proposal is conflating the fragmentation with the
messaging. I explained the solution.

I am sick and tired of my key technical points being railroaded, or
(intentionally or unintentionally) drowned in interminable detailed
pedantic debate. I am trying to get us focused on the key orthogonal base
proposal that will make our detailed work easier to reach concensus on.
For as long as we have the fragmentation conflated with the messaging,
then we are going to keep vacillating because of the fundamental way that
conflation breaks other features we want to do.

As the crucial position of UNBIASED editor, I expect you to be more
thorough and correct in your analysis of the information that is posted to
the list, before you make such sweeping negative allegations against the
minority technical position. When the proponent of the majority proposal
is from your same company, I think recusing yourself would be most noble.

Why can't we find someone as an editor who is truely unbiased and has
shown empathy and thorough technical analysis to everyone's input in past?
Is there not such a person? I understand the former editor Ian Hickson was
removed because he was unbiased.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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.

Post by Ian Fette (イアンフェッティ)
As for any
conflict of interest, I was actually asked by the chairs earlier to

start

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two

proposals,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a

final

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft
b) Simplify the extension question to "does my favorite extension

model

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
work inside the working draft", not "which extension model is

best."

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft. Not shutting down the encoding questions, but letting us

pick

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
a

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
temporary working model so we can move forward.
The objections I've seen to John's encoding have been around

optimality,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
which we can put off temporarily.

Agreed I guess. Although John's proposal is fundamentally different

than

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

https://docs0.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&authkey=CLOirMAE#

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
The way extensions may work should be similar, unless they are

concerned

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
with the framing orthogonality.
The only other difference I can see between John's proposal and mine

(my

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
1
'MORE' bit in every frame. John's proposal will still need the

message

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
The reciever who will defragment, must know the message body length

any

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
if it is continuation, only the messaging layer does.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
reserved.
Then, the extension question simplifies to: can the extension

model

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
work

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
with this frame encoding as a foundation? Assume the extension

model

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
can

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
use
any reserved bits or reserved opcodes it wants to.
-- Scott
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Roy T. Fielding]

Post by Shelby Moore
Also there has not yet been any followup to the technical point I made in
my prior reply on this thread, where I explained that the 4 bits allocated
to the opcode in the frame header are wasted on every fragment. This is
because John's proposal is conflating the fragmentation with the
messaging. I explained the solution.

You apparently type more words in a single day than I write in a year,
so I apologize in advance for not responding to your next six replies.

Post by Shelby Moore
I am sick and tired of my key technical points being railroaded, or
(intentionally or unintentionally) drowned in interminable detailed
pedantic debate. I am trying to get us focused on the key orthogonal base
proposal that will make our detailed work easier to reach concensus on.
For as long as we have the fragmentation conflated with the messaging,
then we are going to keep vacillating because of the fundamental way that
conflation breaks other features we want to do.

Then stop debating them. This is not a debating forum, nor is it
a legal forum. This is a working group for the IETF. Please put your
design in an internet draft and submit it as an individual submission.
Do not include links to all your prior messages and arguments -- just
make a standalone document that describes the design without any
editorial assumptions about how much "better" it is or sophomoric
capitalized phrases intended to provoke meaningless diatribes.
You might discover that people will actually read the draft if
it isn't obscured by link trails and Quixote ripostes.

If that design is adopted by some implementations, then it should be
considered for standardization. Rough consensus and running code, please.

That was the point of my prior message to John as well. Google Docs
is better than email, but is not a substitute for a versioned internet
draft. If you have a proposal to make and it starts branching into
versions and alternatives with extended explanations that could use
serious review, then it belongs in an internet draft. Proposals do
not have to make their first draft appearance in a draft-hybi-*.

Post by Shelby Moore
As the crucial position of UNBIASED editor, I expect you to be more
thorough and correct in your analysis of the information that is posted to
the list, before you make such sweeping negative allegations against the
minority technical position. When the proponent of the majority proposal
is from your same company, I think recusing yourself would be most noble.

No, it would be idiotic. Somebody has to edit the hybi deliverable and
it is absolutely irrelevant what company they work for since the contents
are supposed to reflect rough consensus of the group as a whole, where
that consensus is demonstrated by running code.

FTR, the end-to-end principle does not apply to application-level
protocols, and the lack of visibility was the whole point of my
suggestion to use SSH instead of reinventing another opaque
TCP over TCP. Effective use of app-level intermediaries requires
a protocol that has narrow semantics.

....Roy

[Shelby Moore]

[snip]

Thank you for explaining matters as you see them. It helps to understand
what our differences in process may be.

Post by Roy T. Fielding

Post by Shelby Moore
I am sick and tired of my key technical points being railroaded, or
(intentionally or unintentionally) drowned in interminable detailed
pedantic debate. I am trying to get us focused on the key orthogonal base
proposal that will make our detailed work easier to reach concensus on.
For as long as we have the fragmentation conflated with the messaging,
then we are going to keep vacillating because of the fundamental way that
conflation breaks other features we want to do.

Then stop debating them. This is not a debating forum, nor is it
a legal forum. This is a working group for the IETF.

As much as I appreciated your suggestion for us to produce written
proposala so we can cull them, the above is illogical.

There has to be debate in order to ascertain some things, else it will be
akin to shooting darts blind-folded.

Post by Roy T. Fielding
Please put your
design in an internet draft and submit it as an individual submission.

It is impossible for us to go to internet draft stage when we haven't even
decided what extensions or metadata will look like. See my blindness
point above.

Post by Roy T. Fielding
Do not include links to all your prior messages and arguments -- just
make a standalone document that describes the design

What I did was write down the improvements that I think John's proposal
needs. That is why I linked back to his proposal and contrasted it.

Post by Roy T. Fielding
without any
editorial assumptions about how much "better"

We are debating now in this WG the merits of various options for the base
protocol.

Post by Roy T. Fielding
it is or sophomoric
capitalized phrases intended to provoke meaningless diatribes.

Almost-Better-Than-Nothing is used in security IETF internet drafts! Are
you accusing them of being sophomoric? Please read the technical
justification for such terminology:

http://www.ietf.org/mail-archive/web/hybi/current/msg03833.html

Post by Roy T. Fielding
You might discover that people will actually read the draft if
it isn't obscured by link trails and Quixote ripostes.

I understand economics is a measure of practical achievement. Do you want
to compare networth sir?

More saliently, I doubt the practical importance of worring about those
who are emotionally incapable of scrolling 1/4 of a page past links to
read what follows. Again the link above applies.

Post by Roy T. Fielding
If that design is adopted by some implementations, then it should be
considered for standardization. Rough consensus and running code, please.

If that is all we are doing here, then I am wasting my time, and I will
simply go put my adhoc design on a million users before your design
reaches approved standard.

There are no real implementations until you put this into the wild any
way, it is all mostly conjecture.

Post by Roy T. Fielding
That was the point of my prior message to John as well. Google Docs
is better than email, but is not a substitute for a versioned internet
draft.

We are trying to get here, but we have to get over the hurdle of the base
protocol, before we can start versioning, otherwise we are simply
vacillating all over the place.

If your point is I need to simply go build an entire WebSockets on my own,
then yes that is what I predicted before and I am just confirming if that
is true:

http://www.ietf.org/mail-archive/web/hybi/current/msg03687.html

Post by Roy T. Fielding
If you have a proposal to make and it starts branching into
versions and alternatives with extended explanations that could use
serious review, then it belongs in an internet draft. Proposals do
not have to make their first draft appearance in a draft-hybi-*.

Yes that is the route I was taking, and I felt it was most efficient to
simply offer improvements (altenative fork) to John existing proposal.

Post by Roy T. Fielding

Post by Shelby Moore
As the crucial position of UNBIASED editor, I expect you to be more
thorough and correct in your analysis of the information that is posted to
the list, before you make such sweeping negative allegations against the
minority technical position. When the proponent of the majority proposal
is from your same company, I think recusing yourself would be most noble.

No, it would be idiotic. Somebody has to edit the hybi deliverable and
it is absolutely irrelevant what company they work for since the contents
are supposed to reflect rough consensus of the group as a whole, where
that consensus is demonstrated by running code.

How many people have code running John's exact proposal this minute?

I assert 0 since he changed it within past several hours.

My proposal is only a minor modification and big improvement to that.

For the editor to jump immediately to aid John's latest, without at least
noting why he is not including my input, is relevant. Once he did give
his reason, it has further illuminated that he maybe didn't understand the
prior discussions about the 'MORE' bit:

http://www.ietf.org/mail-archive/web/hybi/current/msg03831.html

Post by Roy T. Fielding
FTR, the end-to-end principle does not apply to application-level
protocols, and the lack of visibility was the whole point of my
suggestion to use SSH instead of reinventing another opaque
TCP over TCP. Effective use of app-level intermediaries requires
a protocol that has narrow semantics.
....Roy

I think I understand your technical point, but do you remember John saying
that enterprises will whitelist secure channels? So shouldn't we at least
try to provide visibility to the extent we can?

[Ian Fette (イアンフェッティ)]

Reply inline

Post by Shelby Moore
[snip]
Thank you for explaining matters as you see them. It helps to understand
what our differences in process may be.

Post by Roy T. Fielding

Post by Shelby Moore
I am sick and tired of my key technical points being railroaded, or
(intentionally or unintentionally) drowned in interminable detailed
pedantic debate. I am trying to get us focused on the key orthogonal base
proposal that will make our detailed work easier to reach concensus on.
For as long as we have the fragmentation conflated with the messaging,
then we are going to keep vacillating because of the fundamental way that
conflation breaks other features we want to do.

Then stop debating them. This is not a debating forum, nor is it
a legal forum. This is a working group for the IETF.

As much as I appreciated your suggestion for us to produce written
proposala so we can cull them, the above is illogical.
There has to be debate in order to ascertain some things, else it will be
akin to shooting darts blind-folded.

Post by Roy T. Fielding
Please put your
design in an internet draft and submit it as an individual submission.

It is impossible for us to go to internet draft stage when we haven't even
decided what extensions or metadata will look like. See my blindness
point above.

Post by Roy T. Fielding
Do not include links to all your prior messages and arguments -- just
make a standalone document that describes the design

What I did was write down the improvements that I think John's proposal
needs. That is why I linked back to his proposal and contrasted it.

Post by Roy T. Fielding
without any
editorial assumptions about how much "better"

We are debating now in this WG the merits of various options for the base
protocol.

Post by Roy T. Fielding
it is or sophomoric
capitalized phrases intended to provoke meaningless diatribes.

Almost-Better-Than-Nothing is used in security IETF internet drafts! Are
you accusing them of being sophomoric? Please read the technical
http://www.ietf.org/mail-archive/web/hybi/current/msg03833.html

Post by Roy T. Fielding
You might discover that people will actually read the draft if
it isn't obscured by link trails and Quixote ripostes.

I understand economics is a measure of practical achievement. Do you want
to compare networth sir?
More saliently, I doubt the practical importance of worring about those
who are emotionally incapable of scrolling 1/4 of a page past links to
read what follows. Again the link above applies.

Post by Roy T. Fielding
If that design is adopted by some implementations, then it should be
considered for standardization. Rough consensus and running code,

please.
If that is all we are doing here, then I am wasting my time, and I will
simply go put my adhoc design on a million users before your design
reaches approved standard.
There are no real implementations until you put this into the wild any
way, it is all mostly conjecture.

Post by Roy T. Fielding
That was the point of my prior message to John as well. Google Docs
is better than email, but is not a substitute for a versioned internet
draft.

We are trying to get here, but we have to get over the hurdle of the base
protocol, before we can start versioning, otherwise we are simply
vacillating all over the place.
If your point is I need to simply go build an entire WebSockets on my own,
then yes that is what I predicted before and I am just confirming if that
http://www.ietf.org/mail-archive/web/hybi/current/msg03687.html

Post by Roy T. Fielding
If you have a proposal to make and it starts branching into
versions and alternatives with extended explanations that could use
serious review, then it belongs in an internet draft. Proposals do
not have to make their first draft appearance in a draft-hybi-*.

Yes that is the route I was taking, and I felt it was most efficient to
simply offer improvements (altenative fork) to John existing proposal.

Post by Roy T. Fielding

Post by Shelby Moore
As the crucial position of UNBIASED editor, I expect you to be more
thorough and correct in your analysis of the information that is posted to
the list, before you make such sweeping negative allegations against the
minority technical position. When the proponent of the majority proposal
is from your same company, I think recusing yourself would be most noble.

No, it would be idiotic. Somebody has to edit the hybi deliverable and
it is absolutely irrelevant what company they work for since the contents
are supposed to reflect rough consensus of the group as a whole, where
that consensus is demonstrated by running code.

How many people have code running John's exact proposal this minute?
I assert 0 since he changed it within past several hours.
My proposal is only a minor modification and big improvement to that.
For the editor to jump immediately to aid John's latest, without at least
noting why he is not including my input, is relevant. Once he did give
his reason, it has further illuminated that he maybe didn't understand the
http://www.ietf.org/mail-archive/web/hybi/current/msg03831.html

Shelby, I will admit that I may have misunderstood your proposal when I
first read it. It starts off by saying that it is "significantly better,"
which IMO should be left up to the reader. It goes on to define a structure
that if you look at it, seems to totally disregard fragmentation, but if you
take the time to go through all of the linked emails, seems to indicate that
fragmentation is implied by receiving a first frame with a larger total
message length, and follow on frames until that message length is received?
I must admit I still do not understand how in your proposal fragmentation
would work when the total message length is not known up front.

As for why I immediately "jumped to aid John's latest," Scott made a very
reasonable request, which I was amenable to. It's not to say "John's
proposal is the winner" but rather, his proposal (and its predecessors V,
VI, and VII) have received a lot of discussion with some changes here and
there, but to be honest things get hard to follow when each email is a
reference to 20 other emails. Having everything in a self-contained draft is
much easier to interpret and debate, so I was happy to produce a draft that
reflected what much of the group had been discussing for the past weeks. In
addition to your version being difficult to parse, and to me at least
seeming to re-hash arguments as well as not clearly supporting a use case
deemed important (though I admit I might just not be understanding how it
supports fragmentation without knowing total message length up front), did
not seem as worth while.

Post by Shelby Moore

Post by Roy T. Fielding
FTR, the end-to-end principle does not apply to application-level
protocols, and the lack of visibility was the whole point of my
suggestion to use SSH instead of reinventing another opaque
TCP over TCP. Effective use of app-level intermediaries requires
a protocol that has narrow semantics.
....Roy

I think I understand your technical point, but do you remember John saying
that enterprises will whitelist secure channels? So shouldn't we at least
try to provide visibility to the extent we can?
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

I have not read this yet, there is discussion with the chair ongoing. I
have requested to cc' Ian and John on my private reply.

Will come back to this after that private stuff is completed.

Post by Ian Fette (イアンフェッティ)
Reply inline

Post by Shelby Moore
[snip]
Thank you for explaining matters as you see them. It helps to understand
what our differences in process may be.

Post by Roy T. Fielding

Post by Shelby Moore
I am sick and tired of my key technical points being railroaded, or
(intentionally or unintentionally) drowned in interminable detailed
pedantic debate. I am trying to get us focused on the key orthogonal base
proposal that will make our detailed work easier to reach concensus

on.

Post by Roy T. Fielding

Post by Shelby Moore
For as long as we have the fragmentation conflated with the

messaging,

Post by Roy T. Fielding

Post by Shelby Moore
then we are going to keep vacillating because of the fundamental way that
conflation breaks other features we want to do.

Then stop debating them. This is not a debating forum, nor is it
a legal forum. This is a working group for the IETF.

As much as I appreciated your suggestion for us to produce written
proposala so we can cull them, the above is illogical.
There has to be debate in order to ascertain some things, else it will be
akin to shooting darts blind-folded.

Post by Roy T. Fielding
Please put your
design in an internet draft and submit it as an individual submission.

It is impossible for us to go to internet draft stage when we haven't even
decided what extensions or metadata will look like. See my blindness
point above.

Post by Roy T. Fielding
Do not include links to all your prior messages and arguments -- just
make a standalone document that describes the design

What I did was write down the improvements that I think John's proposal
needs. That is why I linked back to his proposal and contrasted it.

Post by Roy T. Fielding
without any
editorial assumptions about how much "better"

We are debating now in this WG the merits of various options for the base
protocol.

Post by Roy T. Fielding
it is or sophomoric
capitalized phrases intended to provoke meaningless diatribes.

Almost-Better-Than-Nothing is used in security IETF internet drafts! Are
you accusing them of being sophomoric? Please read the technical
http://www.ietf.org/mail-archive/web/hybi/current/msg03833.html

Post by Roy T. Fielding
You might discover that people will actually read the draft if
it isn't obscured by link trails and Quixote ripostes.

I understand economics is a measure of practical achievement. Do you want
to compare networth sir?
More saliently, I doubt the practical importance of worring about those
who are emotionally incapable of scrolling 1/4 of a page past links to
read what follows. Again the link above applies.

Post by Roy T. Fielding
If that design is adopted by some implementations, then it should be
considered for standardization. Rough consensus and running code,

please.
If that is all we are doing here, then I am wasting my time, and I will
simply go put my adhoc design on a million users before your design
reaches approved standard.
There are no real implementations until you put this into the wild any
way, it is all mostly conjecture.

Post by Roy T. Fielding
That was the point of my prior message to John as well. Google Docs
is better than email, but is not a substitute for a versioned internet
draft.

We are trying to get here, but we have to get over the hurdle of the base
protocol, before we can start versioning, otherwise we are simply
vacillating all over the place.
If your point is I need to simply go build an entire WebSockets on my own,
then yes that is what I predicted before and I am just confirming if that
http://www.ietf.org/mail-archive/web/hybi/current/msg03687.html

Post by Roy T. Fielding
If you have a proposal to make and it starts branching into
versions and alternatives with extended explanations that could use
serious review, then it belongs in an internet draft. Proposals do
not have to make their first draft appearance in a draft-hybi-*.

Yes that is the route I was taking, and I felt it was most efficient to
simply offer improvements (altenative fork) to John existing proposal.

Post by Roy T. Fielding

Post by Shelby Moore
As the crucial position of UNBIASED editor, I expect you to be more
thorough and correct in your analysis of the information that is

posted

Post by Roy T. Fielding

Post by Shelby Moore
to
the list, before you make such sweeping negative allegations against

the

Post by Roy T. Fielding

Post by Shelby Moore
minority technical position. When the proponent of the majority

proposal

Post by Roy T. Fielding

Post by Shelby Moore
is from your same company, I think recusing yourself would be most noble.

No, it would be idiotic. Somebody has to edit the hybi deliverable

and

Post by Roy T. Fielding
it is absolutely irrelevant what company they work for since the

contents

Post by Roy T. Fielding
are supposed to reflect rough consensus of the group as a whole, where
that consensus is demonstrated by running code.

How many people have code running John's exact proposal this minute?
I assert 0 since he changed it within past several hours.
My proposal is only a minor modification and big improvement to that.
For the editor to jump immediately to aid John's latest, without at least
noting why he is not including my input, is relevant. Once he did give
his reason, it has further illuminated that he maybe didn't understand the
http://www.ietf.org/mail-archive/web/hybi/current/msg03831.html

Shelby, I will admit that I may have misunderstood your proposal when I
first read it. It starts off by saying that it is "significantly better,"
which IMO should be left up to the reader. It goes on to define a structure
that if you look at it, seems to totally disregard fragmentation, but if you
take the time to go through all of the linked emails, seems to indicate that
fragmentation is implied by receiving a first frame with a larger total
message length, and follow on frames until that message length is received?
I must admit I still do not understand how in your proposal fragmentation
would work when the total message length is not known up front.
As for why I immediately "jumped to aid John's latest," Scott made a very
reasonable request, which I was amenable to. It's not to say "John's
proposal is the winner" but rather, his proposal (and its predecessors V,
VI, and VII) have received a lot of discussion with some changes here and
there, but to be honest things get hard to follow when each email is a
reference to 20 other emails. Having everything in a self-contained draft is
much easier to interpret and debate, so I was happy to produce a draft that
reflected what much of the group had been discussing for the past weeks. In
addition to your version being difficult to parse, and to me at least
seeming to re-hash arguments as well as not clearly supporting a use case
deemed important (though I admit I might just not be understanding how it
supports fragmentation without knowing total message length up front), did
not seem as worth while.

Post by Shelby Moore

Post by Roy T. Fielding
FTR, the end-to-end principle does not apply to application-level
protocols, and the lack of visibility was the whole point of my
suggestion to use SSH instead of reinventing another opaque
TCP over TCP. Effective use of app-level intermediaries requires
a protocol that has narrow semantics.
....Roy

I think I understand your technical point, but do you remember John saying
that enterprises will whitelist secure channels? So shouldn't we at least
try to provide visibility to the extent we can?
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

Post by Ian Fette (イアンフェッティ)
Shelby, I will admit that I may have misunderstood your proposal when I
first read it. It starts off by saying that it is "significantly better,"
which IMO should be left up to the reader. It goes on to define a structure
that if you look at it, seems to totally disregard fragmentation, but if you
take the time to go through all of the linked emails, seems to indicate that
fragmentation is implied by receiving a first frame with a larger total
message length, and follow on frames until that message length is received?

I think you still missed the key point.

What I am saying is that the following two layers are orthogonal:

1) message layer, i.e the semantic payload of the frames
2) fragmentation layer, i.e. the frame headers + frame non-semantic
payload as bytes

The above will be very important, because some extensions may apply to
only 1 or 2 and not both. If you conflate the layers, it is going to be
much more difficult to perfect the extensions that apply to only one of
the layers, e.g. multiplexing applies to layer #2 but not to layer #1.

The above layers are completely orthogonal and the higher layer #1, can
operate without the lower layer #2.

So thus the semantics of the message itself knows its own length. The
length may not even be in bytes, but in "characters" or "records" or what
ever. The message receiver can convert these semantics to byte size and
tell the lower framing layer if there is more data to be expected.

The way this will work is the message receiver (e.g. JS API interface)
will call into the layer #2 and say "give me more bytes up to this
amount". The layer #1 receiver will continue to ask for more data until
it has enough to complete the message, then it will tell layer #2 that the
message is complete and that future data received will be a new message.

Post by Ian Fette (イアンフェッティ)
I must admit I still do not understand how in your proposal fragmentation
would work when the total message length is not known up front.

Simple. The layer #1 receiver simply keeps asking for more data from the
lower layer #2, until it has enough. The layer #1 can be signaled by the
sender of layer #1, by inserting some EOM or other data structure that
signals the end of a stream.

When the size is known at the start of the message, then that size will be
in the start of the message. The sender and receiver on layer #1 know
this, as they both know what data structure semantics they are
communicating (i.e. JSON or whatever). For example, JSON terminates when
the top level object is terminated ('}' character. The JSON parser
terminates.

Post by Ian Fette (イアンフェッティ)
As for why I immediately "jumped to aid John's latest," Scott made a very
reasonable request, which I was amenable to. It's not to say "John's
proposal is the winner" but rather, his proposal (and its predecessors V,
VI, and VII) have received a lot of discussion with some changes here and
there, but to be honest things get hard to follow when each email is a
reference to 20 other emails.

Agreed it is extremely difficult to communicate on this list. And that is
an understatement of incredible degree.

Post by Ian Fette (イアンフェッティ)
Having everything in a self-contained draft
is
much easier to interpret and debate, so I was happy to produce a draft that
reflected what much of the group had been discussing for the past weeks. In
addition to your version being difficult to parse, and to me at least
seeming to re-hash arguments as well as not clearly supporting a use case
deemed important (though I admit I might just not be understanding how it
supports fragmentation without knowing total message length up front), did
not seem as worth while.

Okay I believe you. But why didn't you even ask me? It sure felt like
you had ignored me completely.

Thank you Ian for your so very considerate reply. I apologize to you, I
misjudged you. I pray you can use my design insights, even I am not here
any more to defend them. You will benefit.


==========the following does not apply to you Ian============

(and yes I can hear the penny gallery snicker and say "it is because of
you, you idiot, you should never have spoken about taboo topics")

I am done with this nonsense.

This is not engineering.

I had the above superior design in my head several days ago and it was
drowned out.

And yes it is superior and I think any one who thinks that is arrogant,
needs to read this:

http://esr.ibiblio.org/?p=1404 (Ego is for little people)

Note Eric Raymond is in good with Donald Knuth:

http://esr.ibiblio.org/?p=2491
http://esr.ibiblio.org/?p=2431

Also I highly suggest this for those people that argue that my polymath
posts in this forum are disruptive:

http://esr.ibiblio.org/?p=2426

Yes they are disruptive! That is whole point!

Has any one heard of Creative Destruction?

[Shelby Moore]

The semantic layer #1 is the serialization/encoder (sender) and parser
(receiver) of the message.

The fragmentation layer #2 is the breaking up of the payload bytes in frames.

Please realize those two layers are entirely orthogonal. #1 can be done
simply by opening a TCP channel and sending. #2 can be done on any kind
of data not just WebSockets.

Once you get that, you start to realize just how wonderful it is to think
in terms of orthogonal design.

And contrary to what people wrote, orthogonal design is more efficient and
less complex. Evidence is the 30% of the precious frame header bits that
we recovered with my design as compared to John's conflated design. And
that is only very tip of the iceberg of benefits you will get with my
orthogonal design that can not be obtained with a conflated design, such
as what John proposed.

Also those who assert the fragments can not be reassembled without extra
overhead, are simply wrong. If any person on this list can't handle that
truth, then they can direct their complaint to the responsible party--
their brain.

Post by Shelby Moore

Post by Ian Fette (イアンフェッティ)
Shelby, I will admit that I may have misunderstood your proposal when I
first read it. It starts off by saying that it is "significantly better,"
which IMO should be left up to the reader. It goes on to define a structure
that if you look at it, seems to totally disregard fragmentation, but if you
take the time to go through all of the linked emails, seems to indicate that
fragmentation is implied by receiving a first frame with a larger total
message length, and follow on frames until that message length is received?

I think you still missed the key point.
1) message layer, i.e the semantic payload of the frames
2) fragmentation layer, i.e. the frame headers + frame non-semantic
payload as bytes
The above will be very important, because some extensions may apply to
only 1 or 2 and not both. If you conflate the layers, it is going to be
much more difficult to perfect the extensions that apply to only one of
the layers, e.g. multiplexing applies to layer #2 but not to layer #1.
The above layers are completely orthogonal and the higher layer #1, can
operate without the lower layer #2.
So thus the semantics of the message itself knows its own length. The
length may not even be in bytes, but in "characters" or "records" or what
ever. The message receiver can convert these semantics to byte size and
tell the lower framing layer if there is more data to be expected.
The way this will work is the message receiver (e.g. JS API interface)
will call into the layer #2 and say "give me more bytes up to this
amount". The layer #1 receiver will continue to ask for more data until
it has enough to complete the message, then it will tell layer #2 that the
message is complete and that future data received will be a new message.

Post by Ian Fette (イアンフェッティ)
I must admit I still do not understand how in your proposal
fragmentation
would work when the total message length is not known up front.

Simple. The layer #1 receiver simply keeps asking for more data from the
lower layer #2, until it has enough. The layer #1 can be signaled by the
sender of layer #1, by inserting some EOM or other data structure that
signals the end of a stream.
When the size is known at the start of the message, then that size will be
in the start of the message. The sender and receiver on layer #1 know
this, as they both know what data structure semantics they are
communicating (i.e. JSON or whatever). For example, JSON terminates when
the top level object is terminated ('}' character. The JSON parser
terminates.

Post by Ian Fette (イアンフェッティ)
As for why I immediately "jumped to aid John's latest," Scott made a very
reasonable request, which I was amenable to. It's not to say "John's
proposal is the winner" but rather, his proposal (and its predecessors V,
VI, and VII) have received a lot of discussion with some changes here and
there, but to be honest things get hard to follow when each email is a
reference to 20 other emails.

Agreed it is extremely difficult to communicate on this list. And that is
an understatement of incredible degree.

Post by Ian Fette (イアンフェッティ)
Having everything in a self-contained draft
is
much easier to interpret and debate, so I was happy to produce a draft that
reflected what much of the group had been discussing for the past weeks. In
addition to your version being difficult to parse, and to me at least
seeming to re-hash arguments as well as not clearly supporting a use case
deemed important (though I admit I might just not be understanding how it
supports fragmentation without knowing total message length up front), did
not seem as worth while.

Okay I believe you. But why didn't you even ask me? It sure felt like
you had ignored me completely.
Thank you Ian for your so very considerate reply. I apologize to you, I
misjudged you. I pray you can use my design insights, even I am not here
any more to defend them. You will benefit.
==========the following does not apply to you Ian============
(and yes I can hear the penny gallery snicker and say "it is because of
you, you idiot, you should never have spoken about taboo topics")
I am done with this nonsense.
This is not engineering.
I had the above superior design in my head several days ago and it was
drowned out.
And yes it is superior and I think any one who thinks that is arrogant,
http://esr.ibiblio.org/?p=1404 (Ego is for little people)
http://esr.ibiblio.org/?p=2491
http://esr.ibiblio.org/?p=2431
Also I highly suggest this for those people that argue that my polymath
http://esr.ibiblio.org/?p=2426
Yes they are disruptive! That is whole point!
Has any one heard of Creative Destruction?
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

This is will be my narcissistic post (that word will provide you lots of
fodder I am sure), and simply because I have been meaning to document
this, I set off about analyzing today what Eric Raymond had written, and
it seems to fit with where the discussion ended up here.

And I think perhaps this may be my (2nd to the) final post in this WG
(that is not a promise, but nearly a certainty, because there is no point
to continue here). Ian knows where to reach me in private to ask any
questions on the superior design I contributed, if he wants to. I
appreciate that the WG will probably find a way to not employ it or
attribute it to another person.

Feel free to completely ignore this, attack it, or what ever. However, I
think the following is very relevant to compare how some people in this WG
reacted to me and how Linus Tovald reacted below...

Post by Shelby Moore
http://esr.ibiblio.org/?p=1404 (Ego is for little people)
http://esr.ibiblio.org/?p=2491
http://esr.ibiblio.org/?p=2431
Also I highly suggest this for those people that argue that my polymath
http://esr.ibiblio.org/?p=2426

I am lucky because I had the curse of the UNgifted! I was routinely
underestimated in my life due to my above-average but not genius level
verbal and visual cortex.

I hope you noticed the sub-link in that immediately above link where Eric
Raymond basically put Linus Tovald in his place:

http://lwn.net/2000/0824/a/esr-sharing.php3?

And how Linus responded:

http://esr.ibiblio.org/?p=2426#comment-271424

What is my IQ? Well on standardized tests it is only 130 - 140:

http://www.iqcomparisonsite.com/GREIQ.aspx#Table

But the problem is that it is very difficult to measure the VERY NARROW
(but widely applicable to polymath, e.g. economics, philosophy, etc) area
of IQ where I may be off the charts, because my verbal and visual cortex
is only about 115 - 120 IQ. I am not genius at visual pattern matching. In
the area of visualizing mathematical relationships, the answers just come
to me immediately as if my brain is operating on auto-pilot and I am just
an observer of myself. But the other problem is measuring this capability
is that I am not genius in loading the data points nor communicating the
result. Once I get the data points loaded, then the solution is instant.
So it is extremely difficult to both measure my IQ and for me to
communicate something once I visualize it. I get easily frustrated with
the wall between my mind and shared understanding. That is why I love
programming, because I don't have to communicate anything, the code just
flows straight from my mind. I do best with languages that have a minimum
vocabulary. I have found errors in the online tests with respect to
philosophy questions. I am very unmotivated by a lot of details, I prefer
to remember only the essense or theorem.

Just now, I solved the following puzzle in a matter of minutes, and it
wouldn't have taken me that long except for the fact that I haven't been
doing any geometry for decades so took me just a few minutes to get my
mind in that mode:

Loading Image...

The area of the larger circle is found by using Pythagorean's theorem and
noting that distance from the center of the larger circle to the chord
forms a equilateral triangle which is 1/3 the area of the equilateral of
the 3 similar chords. And then the distance from the center of the smaller
circle to the chord is also found bh/2 = A. Then you've got the radius of
the larger circle.

http://esr.ibiblio.org/?p=2426#comment-271493

I don't know when I started to read, but I do know that I could build
things with my hands and entertain adults in conversation as an infant. At
age of 5, I observed my very high IQ father (big time attorney for oil
companies) and his buddies trying to build a wood platform in the back of
VW bus. Apparently they were struggling with the design. I gave them the
design nonchalantly. In college, my roommate was amazed that I built a
huge bunk bed for us, simply by walking up to a pile of wood and start
sawing and hammering away at full speed without pause. Within a couple of
hours we were finished. I didn't even have to think about how to design
it. He reminded me in email the other day after I hadn't heard from him
for 2 decades, that we were lacking one 2x4 near the end, and luckily it
came floating down the gutter in a rainstorm like a gift from God.

Recently I lost several 100s lines of Javascript due to a brown out. I had
to wait until the next day and was able to retype it almost verbatim. I
had a picture of it in my mind. But I can't do that from the visual
cortex, I don't have genius photographic memory. I am not particularly
good a chess nor Rubiks cube nor remembering a serial pattern, but also I
have never studied how to be good at those.

Eric Raymond is so much more intelligient than me, because he has
amazingly well rounded IQ (and his design visualization may be higher than
mine too):

http://esr.ibiblio.org/?p=2426#comment-271563

And his design visualization is probably higher than mine too, but I seem
to share his generative rule formulation ability, but I can't communicate
it and it takes me a while to be understand that I am applying a
generative rule (it happens on auto-pilot):

http://esr.ibiblio.org/?p=2426#comment-271693

[Shelby Moore]

Maybe the following will help resolve this amicably. I would REALLY LOVE
to finish my help for WebSockets today, so I can leave and get back to my
company work.

It seems to me that John's proposal can be improved by merging the
improvements from my proposal. Then the group can run forward without my
further interference. Or at least my technical concerns could be attached
as footnotes to John's proposal in the WG draft, until a later decision
time.

Also I want to suggest that if you really want the 'MORE' and Continuation
bits, you can define them as an extension. I assert that they are
Almost-Better-Than-Useless (a twist on common security term
Almost-Better-Than-Nothing), so the way to handle that is simply make them
optional extensions that are negotiated. Those who want that feature do
not have to lose it. I don't use that term to create animosity, just as I
don't think the use of Almost-Better-Than-Nothing by others is intended
that way. It is simply to characterize the facts succinctly.

For example, those bits will probably be entirely redundant when the
multiplexing extension is used, so no need to waste FIVE (5) bits.

If those are made optional extensions, then obviously you no longer need
those 4 opcode bits in the frame header for fragments, so might as well
not waste those 4 bits in frame header ever for opcode, simply put the
opcode in the message body.

Thus you will have FIVE (5) MORE BITS FREE FOR EXTENSIONS or to increase
the short length. Perhaps these extra bits will be very useful for
multiplexing control.



=============== non-technical =============
All of you I am sure invested a lot in your technical, not political,
education.

I know there are probably some list members who got their noses pushed
out-of-joint by any one who pushes against medocrity. I don't know any
other way to help, than to state what I think is the truth and make sure
it is not ignored. Because in the end, I will do the truth, even it means
going out into the market to replace bad standards with adhoc ones. I want
to tell each of you, that I have learned so much from you. You don't know
how much I value and love each of you.

God bless everyone. God bless the users.


P.S. Too many humans allow their brains to shut down when triggered by the
PRIMITIVE herd protection mechanism impulse. My admonition of the editor
to be unbiased, is not meant to impress the list members, but rather in
case I decide to make several 10s of 1000s of people aware of the problems
at the IETF. I don't come here to play silly games. I come here to get
serious engineering work done. I take these proceedings seriously, because
standards affect billions of users. It is ridiculous that a few people
here IETF are basically attempting to dictate conflated spaghetti code
onto the world. I have no personal animosity against the editor, John, or
any other person here. It is a professional issue only. If I meet any of
you in person, I would have no personal ill feelings whatsoever.
Professionalism is not about being perfectly polite (as then there can be
no truth seeking), it is about separating our personal emotions from our
professional brains.

Post by Shelby Moore
See below about Almost Better Than Useless 'MORE' bit and waste of 4 bits
in frame header...

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
As Editor, I will happily produce a draft based on John's earlier

VII

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
proposal, based on 7/16/63 aka 1/2/8. Give me some time, the

current

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
draft

Post by Ian Fette (イアンフェッティ)
was very procedural and I would like to take the opportunity to

re-write

Post by Ian Fette (イアンフェッティ)
it
in the format that we've been discussing on the list. I will spend

time

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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?

http://www.ietf.org/mail-archive/web/hybi/current/msg02747.html
http://www.ietf.org/mail-archive/web/hybi/current/msg02752.html
Note that I intend this as a response to your email about the "MORE" bit
as well. I previously made a similar argument for keeping track of state,
e.g. indicate that something is an initial frame in the first frame, and
then you can make do with a single bit rather than having separate
start/continue/end opcodes. However, Dave and others made a reasonable
argument for wanting to explicitly demarcate start/continue/end. While I
don't want to try to speak on Dave and Doug's behalf, as I read your
proposal their argument seems like it would apply to your proposal as
well.

The first link you provided is saying that we need decent error handling
(i.e. CRC), instead of the proposed bits.
The second links you provided above admits math processors have CRC
capabilities and thus is not trying to make a strong argument for the
Almost Better Than Nothing 'MORE' bit. And the second link was contested
http://www.ietf.org/mail-archive/web/hybi/current/msg02795.html
http://www.ietf.org/mail-archive/web/hybi/current/msg02797.html
Apparently there were no followups.
The technical case for the 'MORE' bit is almost non-existent (as well the
continue bit is Almost Better Than Useless too).
Even without CRC error checking, that bit doesn't gain any redundancy that
you don't also get from multiplexing data that will sit on top of the
fragmentation.
If we are truely worried about TCP bit errors (and cosmic rays too), then
we should do a proper CRC error check, because the 'MORE' bit will do
nothing to stop bit errors in the message opcodes, content length, parsing
forks, etc. We can either require proper CRC error check, or we can
delegate it to the application.
Also if we are running on an encrypted TLS channel, then I assume the
decryption will detect such TCP bus bit errors?
Thus there has been no justification presented for conflating the
fragmentation and messaging protocols. I have explained well how to
unconflated them in my proposal. And I have explained how to give us a lot
https://docs0.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&authkey=CLOirMAE#
Also there has not yet been any followup to the technical point I made in
my prior reply on this thread, where I explained that the 4 bits allocated
to the opcode in the frame header are wasted on every fragment. This is
because John's proposal is conflating the fragmentation with the
messaging. I explained the solution.
I am sick and tired of my key technical points being railroaded, or
(intentionally or unintentionally) drowned in interminable detailed
pedantic debate. I am trying to get us focused on the key orthogonal base
proposal that will make our detailed work easier to reach concensus on.
For as long as we have the fragmentation conflated with the messaging,
then we are going to keep vacillating because of the fundamental way that
conflation breaks other features we want to do.
As the crucial position of UNBIASED editor, I expect you to be more
thorough and correct in your analysis of the information that is posted to
the list, before you make such sweeping negative allegations against the
minority technical position. When the proponent of the majority proposal
is from your same company, I think recusing yourself would be most noble.
Why can't we find someone as an editor who is truely unbiased and has
shown empathy and thorough technical analysis to everyone's input in past?
Is there not such a person? I understand the former editor Ian Hickson was
removed because he was unbiased.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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.

Post by Ian Fette (イアンフェッティ)
As for any
conflict of interest, I was actually asked by the chairs earlier to

start

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
In the interest of moving the discussion forward, I have two

proposals,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
a) Take John Tamplin's 1/2/8 encoding as a _working_ draft, not a

final

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft
b) Simplify the extension question to "does my favorite extension

model

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
work inside the working draft", not "which extension model is

best."

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
draft. Not shutting down the encoding questions, but letting us

pick

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
a

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
temporary working model so we can move forward.
The objections I've seen to John's encoding have been around

optimality,

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
which we can put off temporarily.

Agreed I guess. Although John's proposal is fundamentally different

than

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
mine in terms of the orthogonality of framing and messaging (because
messaging opcodes in mine will never go in frame header if the

frames

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
are

https://docs0.google.com/document/edit?id=1nL9VauetwYgYtpgSVRmm8_SgH7K2P15GwaGMEbAizGs&authkey=CLOirMAE#

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
The way extensions may work should be similar, unless they are

concerned

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
with the framing orthogonality.
The only other difference I can see between John's proposal and mine

(my

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
1
'MORE' bit in every frame. John's proposal will still need the

message

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
body for first frame to contain the defragmented message body

length,

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
same
as mine, because the 'MORE' bit doesn't tell you the total message

body

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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.

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
The reciever who will defragment, must know the message body length

any

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
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

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
if it is continuation, only the messaging layer does.

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
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

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
reserved.
Then, the extension question simplifies to: can the extension

model

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
work

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
with this frame encoding as a foundation? Assume the extension

model

Post by Ian Fette (イアンフェッティ)

Post by Ian Fette (イアンフェッティ)
can

Post by Ian Fette (イアンフェッティ)

Post by Scott Ferguson
use
any reserved bits or reserved opcodes it wants to.
-- Scott
_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
https://www.ietf.org/mailman/listinfo/hybi

[Shelby Moore]

Seems that once John clarifies that his 'MORE' bit doesn't do anything
useful, and once he clarifies that the opcode bits can't be used for
messaging opcodes in continuation fragments, then essentially our
proposals are the same?

Seems like we might be arguing about nothing?

But first I have somehow to get John to realize that his 'MORE' bit
provides no function.

And then to get clarification on what John's opcode field is used for in
fragments?

Post by Shelby Moore

Post by Scott Ferguson
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
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.

[Shelby Moore]

Post by Shelby Moore
Seems that once John clarifies that his 'MORE' bit doesn't do anything
useful, and once he clarifies that the opcode bits can't be used for
messaging opcodes in continuation fragments, then essentially our
proposals are the same?
Seems like we might be arguing about nothing?
But first I have somehow to get John to realize that his 'MORE' bit
provides no function.
And then to get clarification on what John's opcode field is used for in
fragments?

Post by Shelby Moore

Post by Scott Ferguson
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
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.

I just realized that John's 'MORE' bit has one unnecessary use case. It
can be used (when it is 0 on the first frame of a message) to signify that
the frame size dictates the message body size in bytes. That could
potentially avoid putting the message body size in the message body in
that case where there is no fragmentation.

I have handled that in my proposal by saying that frame size can be used
for the message body size in bytes for lengths < 254. Otherwise there is
always a message body length in the message body.

So thus mine saves one bit in the header _ALWAYS_, and for the < 254 case
mine is equivalent in efficiency PLUS saves one bit in header. For > 253,
it really doesn't matter, so no advantage to using a 'MORE' bit.

Besides, most messages are going to have a separate content-length in
units other than bytes, i.e. UT8 characters and other encodings.

So I really can not find any rational for the 'MORE' bit, which is what I
have been saying since the CML thread.

[Shelby Moore]

Post by Shelby Moore

Post by Shelby Moore
Seems that once John clarifies that his 'MORE' bit doesn't do anything
useful, and once he clarifies that the opcode bits can't be used for
messaging opcodes in continuation fragments, then essentially our
proposals are the same?
Seems like we might be arguing about nothing?
But first I have somehow to get John to realize that his 'MORE' bit
provides no function.
And then to get clarification on what John's opcode field is used for in
fragments?

Post by Shelby Moore

Post by Scott Ferguson
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
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.

I just realized that John's 'MORE' bit has one unnecessary use case. It
can be used (when it is 0 on the first frame of a message) to signify that
the frame size dictates the message body size in bytes. That could
potentially avoid putting the message body size in the message body in
that case where there is no fragmentation.
I have handled that in my proposal by saying that frame size can be used
for the message body size in bytes for lengths < 254. Otherwise there is
always a message body length in the message body.
So thus mine saves one bit in the header _ALWAYS_, and for the < 254 case
mine is equivalent in efficiency PLUS saves one bit in header. For > 253,
it really doesn't matter, so no advantage to using a 'MORE' bit.
Besides, most messages are going to have a separate content-length in
units other than bytes, i.e. UT8 characters and other encodings.
So I really can not find any rational for the 'MORE' bit, which is what I
have been saying since the CML thread.

Moving on from the Almost Better Than Useless 'MORE' bit, I am seeing that
John wastes 4 bits in every header for an opcode which is unnecessary for
all fragments, because their opcode will be 0 = continuation.

Instead what he should do is put the opcode in the message data since it
will only occur on the first frame (head of the message body). And then
if he really needs a continuation bit in the header, he can save 3 bits in
every header!

In my proposal, I make a special case for non-fragmented frames < 254
size, to put the opcode in the header to reduce a byte from the message
body.

=========== extra credit ============
I am assuming we can deduce the continuation bit from the message content
parsing. And I assume the messaging receiver can communicate this to the
framing layer which is defragmenting (reassembling).

So I don't think we need the continuation bit either, but if you really
think you need it, then you can put in my proposal too. But note that the
continuation bit conflates the fragmentation layer with the message
content layer, which is bad thing to do, because then it is harder to
unconflate them if your messaging receiver depends on that continuation
bit (it shouldn't, which is the point).