Subject: [Dime] The M-bit MAY column issue

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 8 Oct 2008 21:59:30 +0300

Hi all, 

the M-bit setting in an AVP indicates what the receiving side has to
understand. From an implementation point of view there are only these
two options:  
* I have to implement the AVP.
* I don't have to implement it. It's optional.  

For the sending side the ABNF tells what the sender has to put into a
command (with some additional constraints). 

When one restricts the M-bit setting to 
-- MUST and 
-- MUST NOT 
then the semantic regarding what has to be implemented and understood is
essentially determined at the time when the specification was written
and this raises the question about why that information is carried in
the protocol itself (rather than just written in the specification very
much like the ABNF is).

Some folks in the past suggested to remove the MAY option of the M-bit.
My question is: Why is the M-bit flag in the AVP needed at all?  Why
don't we replace it with a table in the document that says which AVPs
must get implemented and which others are optional? 

Ciao
Hannes
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 8 Oct 2008 21:53:36 +0200

For me, the use of the M-bit allows to "optionally" send any AVPs in a given command and to be sure that these AVPs will not be simply ignored if not understood.

If you want to remove the M-bit, you will have to specify per command in the same table:
*All the AVPs that will be always present in the command (i.e. fixed and required AVP)
*All the AVPs that may be added in the command and must not be ignored if not supported
*Any other AVP that may be present in the command and may be ignored if not supported.

I think it would be easier to keep the M-bit flag as it is.
I'm assuming that the majority of the AVPs used in a given application will have a fixed setting of the M-bit (set or cleared) - that could be stated some where...
If still required, it would be however possible to indicate that a specific AVP would have "always" the M-bit set except in such or such a command. That means that this clarification would be needed only for these specific AVPs.

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Tschofenig, Hannes (NSN - FI/Espoo)
> Envoyé : mercredi 8 octobre 2008 21:00
> À : [email-masked]
> Objet : [Dime] The M-bit MAY column issue
> 
> Hi all, 
> 
> the M-bit setting in an AVP indicates what the receiving side 
> has to understand. From an implementation point of view there 
> are only these two options:  
> For the sending side the ABNF tells what the sender has to 
> put into a command (with some additional constraints). 
> 
> then the semantic regarding what has to be implemented and 
> understood is essentially determined at the time when the 
> specification was written and this raises the question about 
> why that information is carried in the protocol itself 
> (rather than just written in the specification very much like 
> the ABNF is).
> 
> My question is: Why is the M-bit flag in the AVP needed at 
> all?  Why don't we replace it with a table in the document 
> that says which AVPs must get implemented and which others 
> are optional? 
> 
> Ciao
> Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 9 Oct 2008 19:59:55 +0300

Hi Lionel, 

>For me, the use of the M-bit allows to "optionally" send any 
>AVPs in a given command and to be sure that these AVPs will 
>not be simply ignored if not understood.

I would phrase it a bit differently (since the M-bit is independing of the
ABNF, i.e., what is being sent) but the outcome would be the same. 

>
>If you want to remove the M-bit,

Some other folks in the group suggested it. I am only stating what it
essentially means. 

 you will have to specify per 
>command in the same table:

The information about what AVPs are being sent in each command has to be
provided anyway, regardless of the M-bit discussion as it is contained in
the ABNF of the command. 

 *All the AVPs that may be added in the 
>command and must not be ignored if not supported

This is essentially an AVP that has the M-bit set.

 *Any other 
>AVP that may be present in the command and may be ignored if 
>not supported.

This is essentially an AVP that does not have the M-bit set. 

>I'm assuming that the majority of the AVPs used in a given 
>application will have a fixed setting of the M-bit (set or 
>cleared) - that could be stated some where...

There are only two choices when the MAY option is removed. 

>If still required, it would be however possible to indicate 
>that a specific AVP would have "always" the M-bit set except 
>in such or such a command. That means that this clarification 
>would be needed only for these specific AVPs.
>

Ciao
Hannes

>> De : [email-masked] [mailto:[email-masked]] De la part 
>> de Tschofenig, Hannes (NSN - FI/Espoo) Envoyé : mercredi 8 octobre 
>> 2008 21:00 À : [email-masked] Objet : [Dime] The M-bit MAY 
>column issue
>> 
>> Hi all,
>> 
>put into a 
>understood 
>> is essentially determined at the time when the specification was 
>> written and this raises the question about why that information is 
>> carried in the protocol itself (rather than just written in the 
>> specification very much like the ABNF is).
>>