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 (イアンフェッティ)
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 (イアンフェッティ)
2010-08-28 00:20:05 UTC
Permalink
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
2010-08-28 00:33:31 UTC
Permalink
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 (イアンフェッティ)
2010-08-28 04:38:03 UTC
Permalink
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
postI will spend-->
work inside the working draft",]y{c]cycu[yau[yau[yau[yau[yau[yau[yau[yawor[Q the extenƒãƒ†ã‚£)-->
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ũQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral l l l l l l l pqbQral ¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£)
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 currentdraft
Post by Ian Fettetetetety procedural and I would like to take the opportunity to
re-write
Post by Ian Fette (イアンフェッティ)
it
i>i>i>i>rmat that we've been discussing on the list. I will spend
postI will spend--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)--><><><><>)Post by I