Subject: Re: [Dime] Diameter Group: Type?

From: Avi Lior <[email-masked]>
Date: Thu, 17 Mar 2011 17:35:25 -0400

Hi All,

Just summarizing and reasserting my objection.

There are two issues here:
A) Should we have a bit definition for a grouped AVP.

B) Can bits be defined by Applications etc; and

WRT to (A). And putting aside (B).  I haven't heard any compelling reason
to add the G-bit.  As stated by more then one person: You either support
the
AVP based on its command code or not - whether its a grouped AVP or not
only becomes when you have to dive in to it - and you would only do that
for an AVP that you support. And you would know the type of the AVP
(whether it is an int or a group etc) if you support the AVP.

As to B) I agree with Glen.  As per the specification an Application can
define its own AVP flag.
Thus if an application writer can design a new Application and add a G-Bit
if they want.

What we cant do is add the G-bit as a general mechanism that can be
applied to all application (like the M-bit) and this is because (as
mentioned on this thread) the specification was not written properly and
we cant deal with such modification and not break things.  See "the
senders shall set to zero(clear) and receivers shall ignore" discussion.
We can't fix that in BIS since it will break existing applications.  We
could say that new applications shall include the above statement.  We can
also RECOMMEND that new application don't define their own AVP bits (if we
want).  This may create a bit of a war as those entities that have done so
come out of the wood work.  Do we know anyone that has done that?

Here is some text:

It is recommended that new Applications not define their own AVP flags
bits.

New Applications shall treat any reserved AVP flag bits as follows:  The
sender of the AVP shall clear (set to zero) all reserved AVP flag bits and
receivers shall ignore all reserved AVP flag bits.

Is there anything to fix in BIS.  Yes.

We need to state somewhere that if an existing application changes the
meaning/semantics of their AVP Flags then a new Application ID must be
assigned to that application.

This could be added to the section describing when to get a new
Application ID.

In V2 we can support properly the notion of applications defining their
own Flag bits (yuck) or not (my vote)

-- Avi Lior
--Bridgewater Systems