Subject: [AAA-WG]: Application support in Diameter

From: <[email-masked]>
Date: Tue, 4 May 2004 10:38:17 +0300

Hi all,

There have been a number of mails about Application IDs and mandatory AVPs, and
so forth in Diameter.  It seems that there is a desire to support application
versioning (at least adding new mandatory AVPs to existing applications.

It is my opinion that an implementation adding additional mandatory AVPs cannot
be considered conformant to the Diameter Application if it does this.  A Diameter
implementation receiving a command with a new mandatory AVP is not required
to process the message in any way.  It MAY send an error with error code 5001,
but is not required to.  Additionally, if more than one unsupported mandatory AVP 
is sent, Section 7 says:

   The Result-Code AVP describes the error that the Diameter node
   encountered in its processing.  In case there are multiple errors,
   the Diameter node MUST report only the first error it encountered
   (detected possibly in some implementation dependent order).  

Therefore, it is problematic to add mandatory AVPs to existing implementations
and it is the intent of the Diameter Base Specification to require a new Application
in instances when new mandatory AVPs are required.

John

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 May 2004 09:05:14 -0700 (PDT)

> in instances when new mandatory AVPs are required.

I believe that John is correct here.  We had a very long discussion about
this issue before RFC 3588 was approved as an RFC.  By requiring a new
application Id if new mandatory AVPs are added, Diameter ensures
interoperability.  Any peer that advertises an application Id can support
that application.  This is important not only to Diameter clients and
servers, but also to intermediaries, since the CER/CEA is built on
application advertisements.

That said, it *is* possible to add non-mandatory AVPs without changing the
Application Id.  And I think there may be some confusion about the meaning
of "non-mandatory".  This simply means that if you don't understand the
AVP you can ignore it.  It is still possible for other peer to change
their behavior based on support of the AVP -- but they can't *require* it.

So I believe that in theory, "sub-versioning" based on a non-mandatory AVP
is legal within Diameter.  Whether this is a good idea is another matter.