RE: : ISSUE: Extensibility of commands (Result-Code)

Since Diameter commands are meant to be reused by different Diameter
applications, I understand that this should be the case for the 
commands in the Diameter SIP application too.  How is a vendor specific
application going to use this command if it is not possible to add
the vendor application id in it?

Or is it that vendor specific applications can only use commands that
are not defined by IETF?

> -----Original Message-----
> From: Miguel Garcia [mailto:[email protected]]
> Sent: viernes, 28 de octubre de 2005 10:39
> To: German Blanco (E2/EEM)
> Cc: '[email protected]'; J.Javier Pastor (E2/EEM)
> Subject: Re: [AAA-WG]: ISSUE: Extensibility of commands (Result-Code)
> 
> 
> An analysis of this issue:
> 
> I start by clarifying that the Diameter Cx application is a 
> vendor-specific application, whereas the Diameter SIP application is 
> not, it will be a standard track document.
> 
> Thus, there is not a vendor-specific application allocated to the 
> Diameter SIP application, and thus, IMHO it makes no sense to allow 
> vendor-specific experimental result codes in the Diameter SIP app.
> 
> The text in RFC 3588 that you are referring, about the 
> incompatibility 
> of Result-Code with Experimental-Result-Code... I guess you 
> refer to the 
> following text:
> 
>     All Diameter answer messages defined in vendor-specific
>     applications MUST include either one Result-Code AVP or one
>     Experimental-Result AVP.
> 
> Obviously, as I indicated, the Diameter SIP application is NOT a 
> vendor-specific applicaion, and thus, first can't contain 
> Experimental-Result, and second, the above text does not apply.
> 
> In my opinion this issue is rejected.
> 
> /Miguel
> 
> 
> 
> German Blanco (E2/EEM) wrote:
> 
> > Description of issue: Message formats are not open to 
> vendor extensions II
> > Submitter name: German Blanco
> > Submitter email address: [email protected]
> > Date first submitted: 27 Oct 05
> > Document: sip
> > Comment type: T
> > Priority: 1
> > Sections: 7
> > Rationale/Explanation of issue: All the answer messages 
> defined in the draft
> > have a mandatory Result-Code AVP.  That makes it impossible 
> for a vendor to add 
> > additional result codes, since only one of Result-Code and 
> Experimental-Result
> > AVPs may be present in the message, according to RFC 3588.
> > 
> > Requested change: Change the message formats so that 
> Result-Code is optional.
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email protected]
> Nokia Research Center      Helsinki, Finland
> 
>