Subject: [Forces-protocol] header: flags vs commands

From: Jamal Hadi Salim <[email-masked]>
Date: 07 May 2004 08:24:40 -0400

Just changed the subject to map the two conversations under the same
subject header.

On Thu, 2004-05-06 at 22:26, Khosravi, Hormuzd M wrote:
[HK] For some cases in our case, such as 2-phase commit, I think it
> makes sense to have flags only in the message body or the TLV that we
> define for that msg rather than the msg header. But I don't want to be
> too picky about this either. Let us know if you're fine with this
> (having flags in msg body) ? 
> 
> BTW, we don't need to have 16 bits for Flags in the common header if we
> don't need them. We can just do with 4-5 bits for example, if that is
> sufficient.

On Fri, 2004-05-07 at 01:19, Weiming Wang wrote:
[Weiming]Jamal, I think we all have no doubt that to subscribe/unsubscribe
> events is definitely necessary. The difference between Hormuzd and me is if we
> need to have specific msgs to do this or not. My idea is it can be very easily
> done by config msg, therefore we don't need a specific msg (according to Hormuzd
> idea, 4 msgs, sub and resp, unsub and resp) to do this. In this way, we actually
> treat the sub/unsub as an FE attribute, behind which is actually an event
> sub/unsub table. My idea is we have just used a quite synthisized msg mode, why
> should we spend so many msgs in this very tiny task then.

Let me talk about something related first:
My view is we need those flags in the header. It doesnt make sense to be 
protective of 12 bits (restricting flags to 4 bits). While i am against over
zealous future-proof designs, i think at this stage of the game we cant 
afford to be extreme on the other end of the stick either.
So my thoughts: 16 bit flags and 16 bit command. I dont see a big deal of using
20 more bits (come on, guys - some people are preaching XML, imagine the million
of bits overhead per second there).
Note i dont have a problem using the headers on the T part of things in the 
message body. However, i think those are very precious(not many bits) and we 
should use them cautiously.

Now to the issue at hand of whether to use more commands or extend commands via
flags.
Like i said earlier, i am indifferent; however, i have used the second scheme
and it worked well (and i know a lot of protocols using it) and for that reason 
i am biased towards it. 
Hormuzd, what is it that is attractive to have the use of commands instead of 
the flags extensions? Is it implementation experience, another protocol you 
are familiar with, or you just think it is cleaner. If cleaner, contrasting against
the flag extension, why is it better? 

I dont think we should stall on this. so lets resolve this and move on.

cheers,
jamal

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 10 May 2004 10:36:00 -0700

Jamal,

Sorry for the late response. See my reply below.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

protective of 12 bits (restricting flags to 4 bits). While i am against
over
zealous future-proof designs, i think at this stage of the game we cant 
afford to be extreme on the other end of the stick either.
So my thoughts: 16 bit flags and 16 bit command. I dont see a big deal
of using
20 more bits (come on, guys - some people are preaching XML, imagine the
million
of bits overhead per second there).
Note i dont have a problem using the headers on the T part of things in
the 
message body. However, i think those are very precious(not many bits)
and we 
should use them cautiously.

Now to the issue at hand of whether to use more commands or extend
commands via
flags.
Like i said earlier, i am indifferent; however, i have used the second
scheme
and it worked well (and i know a lot of protocols using it) and for that
reason 
i am biased towards it. 
Hormuzd, what is it that is attractive to have the use of commands
instead of 
the flags extensions? Is it implementation experience, another protocol
you 
are familiar with, or you just think it is cleaner. 

[HK] Its implementation experience, more efficient parsing, efficient
use of bits and cleaner.

[HK] Sure, I agree. I don't want us to stall on this either. Let us know
your thougts ? If you don't agree, we can move forward with what you
guys think is best.

Regards
Hormuzd