Re: : ISSUE: Extensibility of commands (Auth-Application- Id)

On 10/29/05, German Blanco (E2/EEM) <[email protected]> wrote:
>
> OK, if the ABNF of the command can be changed without restrictions
> for each application then these two issues about the application
> id and the result code do not make sense.
>
> German.

It seems that this issue comes up every couple of months. Some people
seems to think that the Vendor-ID, Support-Vendor-ID,
Vendor-Specific-Application-ID and similar attributes are supposed to
be set to the vendor that produced that software. A big part of the
conclusion comes from the word "application" that doesn't point to the
software implementation itself, but to the exact protocol itself
(derived from the Base protocol). I've seen a case where a
subcontractor was using 6 (six) different vendorids in the CER (1 real
one, and 5 supported vendor-ids) and , although it was supposed to be
a simple Cx interface.

When a vendor only wants to add an extra attribute to a command, and
it's an optional attribute (transparent for other vendors), then the
ABNF hasn't been changed, and there's no need to use a new command
code or apply for a whole new (vendorspecific) application-id. As long
as application from other vendors can safely ignore the unrecognized
attribute without affecting the behaviour, there won't be any problem.

When a new attribute is added that is mandatory, then you should apply
for a command-code (and a application-id), because the ABNF isn't
compatible anymore. You can still try to send the attribute with the M
flag set, but then you risk a DIAMETER_AVP_UNSUPPORTED, or a
proxy-server might not wanting to forward the request. No harm is
done, although it's against the spirit of DIAMETER. You should have
created a new command-code and a application-id. Or you can try to
resend the request without the offending attribute.

New command-codes in existing applications won't be recognized by
remote servers, so you receive a DIAMETER_COMMAND_UNSUPPORTED. Again,
it's not fatal, and the application might survive. But it would be
better to use a complete new application-id for this.

--
Jo Hermans

"Eagles may soar, but weasels aren't sucked into jet engines"