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

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.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: viernes, 28 de octubre de 2005 11:00
> To: [email protected]
> Subject: RE: [AAA-WG]: ISSUE: Extensibility of commands
> (Auth-Application-Id)
> 
> 
> Hi,
> 
> This change is not needed. If the command is sent with a
> Vendor-Specific-Application-Id it means that the ABNF of the
> command can be different compared to the ABNF of the command
> sent with a standard application-id.
> 
> It's correct that in Diameter SIP the Auth-Application-Id AVP
> is a required AVP.
> 
> 
> BR,
> Mikko
>  
> 
> > -----Original Message-----
> > From: [email protected] 
> > [mailto:[email protected]]On Behalf Of
> > ext German Blanco (E2/EEM)
> > Sent: 27 October, 2005 18:21
> > To: '[email protected]'
> > Cc: J.Javier Pastor (E2/EEM)
> > Subject: [AAA-WG]: ISSUE: Extensibility of commands
> > (Auth-Application-Id)
> > 
> > 
> > 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.
> > 
>