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

<[email protected]> Fri, 28 Oct 2005 12:01:51 +0300
Newsgroups gmane.ietf.aaa
Message-ID <[email protected]>
Hi,

> 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.

I agree.


BR,
Mikko


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext Miguel Garcia
> Sent: 28 October, 2005 11: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
> 
>