Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification

From: [email-masked]
Date: Mon, 22 Oct 2001 19:23:16 +0300

Hi,

> What this section proposes is that each AVP name have an 
> alternate name, 
> increasing the confusion in the protocol.
> 
> Why does the Diameter protocol require alternate names for AVPs?

The proposal allows to contruct commands where it is required (or fixed or
optional) to include one of the alternatives in the ABNF definition. This is
not like allowing to have alternate names for AVPs for no reason at all. For
example, in the following command definition:  

      Example-Request ::= < Diameter-Header: 9999999, REQ, PXY >
                          { User-Name }
                          { Origin-Host }
                          { example1_AVP / example2_AVP }
				* [ AVP ]

The Example-Request command MUST have either example1_AVP or example2_AVP.
These type of definitions are quite common but they are not possible with
the current command code ABNF specification.

Or as in the following example below, the Example-Request command can
optionally have either example1_AVP or example2_AVP and nothing else.

      Example-Request ::= < Diameter-Header: 9999999, REQ, PXY >
                          { User-Name }
                          { Origin-Host }
                          [ example1_AVP / example2_AVP ]

> PatC

Best Regards, Jaakko

> -----Original Message-----
> From: ext Pat Calhoun [mailto:[email-masked]]
> Sent: 22 October, 2001 18:17
> To: Rajaniemi Jaakko (NET/Espoo)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command 
> Code ABNF
> specification
> 
> 
> On Thu, Oct 18, 2001 at 04:33:55PM +0300, 
> [email-masked] wrote:
> >  
> > Submitter name: Jaakko Rajaniemi 
> > Submitter email address: [email-masked] 
> > Date first submitted: 2001-10-18 
> > Document: base 
> > Comment type: T 
> > Priority: 1 
> > Section: 3.2 
> > Rationale/Explanation of issue: 
> > 
> > The section 3.2 "Command Code ABNF specification" contains the ABNF
> > specification which must be followed when contructing 
> Diameter Command
> > Codes. It does not contain a possibility to use the 
> alternatives (see
> > RFC2243, section 3.2) when defining the AVPs included into 
> the commands.
> > This is very restrictive and does not allow enough 
> flexibility when defining
> > command codes and therefore it is proposed that the alternatives is
> > included. 
> > Requested change:
> > 
> > Include following description to the avp-spec in the section 3.2:
> >  
> > avp-spec         = diameter-name *("/" diameter-name)
> >                   ; The avp-spec has to be an AVP Name, 
> > 			; defined in the base or extended Diameter
> >                   ; specifications. The avp-spec may 
> contain AVP Names 
> > 			; which are alternatives, see RFC 2234 
> section 3.2.
> 
> What this section proposes is that each AVP name have an 
> alternate name, 
> increasing the confusion in the protocol.
> 
> Why does the Diameter protocol require alternate names for AVPs?
> 
> PatC
>

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 22 Oct 2001 12:46:11 -0700

Ah, I like it.

Others?

PatC