Discussion:
[hybi] a working draft, not a final draft
Scott Ferguson
2010-08-27 21:02:33 UTC
Permalink
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
2010-08-27 21:11:41 UTC
Permalink
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.
--
John A. Tamplin
Software Engineer (GWT), Google
Scott Ferguson
2010-08-27 21:45:23 UTC
Permalink
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
2010-08-27 21:57:42 UTC
Permalink
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?
--
John A. Tamplin
Software Engineer (GWT), Google
Scott Ferguson
2010-08-27 22:45:24 UTC
Permalink
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
2010-08-27 22:56:39 UTC
Permalink
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.
--
John A. Tamplin
Software Engineer (GWT), Google
Shelby Moore
2010-08-27 21:13:38 UTC
Permalink
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
2010-08-27 22:24:30 UTC
Permalink
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
2010-08-27 22:02:27 UTC
Permalink
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.
--
John A. Tamplin
Software Engineer (GWT), Google
Ian Fette (イアンフェッティ)
2010-08-27 23:03:09 UTC
Permalink
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
2010-08-27 23:10:41 UTC
Permalink
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
2010-08-27 23:32:16 UTC
Permalink
Post by Ian Fette (イアンフェッティ)