Re: QoS NSLP flags

Hi Martin and all,

Martin Stiemerling wrote:
>> On 01/26/2009 02:49 PM Martin Stiemerling wrote:
>> confusion. For example something like this: »Any bit not defined as
>> a flag for a particular message MUST be set to zero on sending,
>> MUST be ignored on receiving, and MUST be forwarded unchanged.«
> 
> Isn't this reading contradicting? An QoS NSLP node that forwards a
> message, must anyhow first receive it. So, does this mean to change
> or leave the bit?

I guess that he meant to leave the bit intact, but you're correct
that the third statement contradicts the first. Leaving unknown bits
intact would allow for easier extensibility. For message objects we have
the the A/B flag mechanism, but for message flags this won't work.
The Postel principle actually would propose to ignore unknown
bits on receipt and reset unknown bits to zero for outgoing messages.
Leaving unknown bits intact would require to save the unknown flags
for the outgoing message thus making implementations a little bit more
complex. But as far as I can see resetting or leaving bits are both
problematic to the same extent, depending on the bits meaning.
If a new bit is used to signal some kind of node capability, then
leaving bits intact would be problematic. If the new bit is used to
signal a special meaning to the far end node, then leaving bits intact
would be nice. So currently, if we need to introduce extra bits, we
require a new NSLP protocol version, right?

Regards,
 Roland