Re: [hybi] Framing take IV

[Greg Wilkins <[e-mail]>]

Jamie,

sorry the text diagrams are not working... they should be in fixed width fonts.

Anyway - I'm trying to work out the exact nature of your proposal other than
what I think are stylistic (eg opcode + length  vs BERlength + opcode )

So I think the key aspect of your  proposal I think is that the
extended op codes are negotiated in the handshake.
You say that the *client* decides opcode values for features it
proposes, but how does the client know what features the server
supports?
Surely it is best for the client to simply list the extensions it may
support and then the server picks the final list and allocates opcodes
(and/or bits)?
Could you possible do some more worked examples of how you see this
working - eg if I wanted to negotiate fragments, mime messages and
compressed frames.


Eitherway, if opcodes were able to be negotiated, then would you agree
that this would work with the binary framing more or less how it is
currently
specified;

    op-code(8) + BER length + data


I ask this because the current framing is our starting point.  I know
there are arguments for
    opcode + fixed length
    opcode + BER length
    BER opcode + BER length
    fix length + opcode
    BER length + opcode
    BER length + BER opcode

but I think they are secondary to the basic extension mechanism and
I'd really like to separate out discussion of what is the best length
encoding from what is a sufficient extension mechanism.

cheers