Re: : 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