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

This issue has a similar resolution as the Result-Code issue that we 
discuss earlier. To summarize:

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

The text in RFC 3588 that you are referringto the following text:

    The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
    Grouped and is used to advertise support of a vendor-specific
    Diameter Application.  Exactly one of the Auth-Application-Id and
    Acct-Application-Id AVPs MAY be present.

Obviously, as I indicated, the Diameter SIP application is NOT a 
vendor-specific applicaion, and thus, first can't contain 
Vendor-Specific-Application-Id, and second, the above seems to apply to 
the advertisement of applications, which is not the case for any of the 
commands of the Diameter SIP application.

In my opinion this issue is rejected.

/Miguel

German Blanco (E2/EEM) wrote:

> Description of issue: Message formats are not open to vendor extensions I
> 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 commands defined in the draft
> have a mandatory Auth-Application-Id AVP.  That makes it difficult to
> use the command in a vendor application, since a vendor application
> should use the command with a Vendor-Application-Id AVP and in RFC 
> 3588 it is stated that only one of these AVPs may be present.
> 
> Requested change: Change the message formats so that Auth-Application-ID
> is optional.
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email protected]
Nokia Research Center      Helsinki, Finland