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

From: [email-masked]
Date: Thu, 25 Oct 2001 11:25:51 +0300

Erik,

I feel you have misunderstood what is being proposed by Jaakko. The proposal
is NOT to touch the terminals (AVP definitions) at all, but to allow
*command definitions* where _either_ AVP1 _or_ AVP2 is required. AVP1 and
AVP2 being defined elsewhere.

Maybe the source of the confusion is the location of the "/" delimiter in
Jaakko's proposal. In the RFC 2234 ABNF the "<>"'s around elements are not
required. In the Diameter specs each AVP name is included in some kind of
brackets separately. If this is to be continued, the alternative delimiter
"/" should be outside of the brackets, but then additional parentheses may
be needed, unless line breaks are made syntactically significant.

Example (using the syntax proposed in issue 200):

Session-Termination-Req ::= < Diameter Header: 275, REQ, PXY >
				    < Session-Id / User-Name >
				    ...

This would allow Session Termination to be issued either based on the
Session-Id AVP, or the User-Name AVP (Current definition requires both).

Maybe a more proper syntax would be:

Session-Termination-Req ::= < Diameter Header: 275, REQ, PXY >
				    < Session-Id > / < User-Name >
				    ...

Here the line breaks are understood to limit the effect of the alternative
delimiter. If this is not acceptable, then consider:

Session-Termination-Req ::= < Diameter Header: 275, REQ, PXY >
				    (< Session-Id >) / (< User-Name >)
				    ...

But this is kind of ugly...

An alternative to the whole proposal is that two different commands are
defined.

Example:

Session-Termination-1-Req ::= < Diameter Header: 275, REQ, PXY >
					< Session-Id >
					...

and 

Session-Termination-2-Req ::= < Diameter Header: 999, REQ, PXY >
					< User-Name >
					...

As the kind of brackets used denotes the "requiredness" of the AVP, maybe
the simplest change to the command definition grammar adding alternatives
would be to allow multiple AVPs to be included in one pair of brackets.
Modified rules could be like this:

      fixed            = [qual] "<" 1*avp-spec [ "/" 1*avp-spec ] ">"
                         ; Defines the fixed position of an AVP sequence.
                         ; Either the AVPs before OR after the "/" delimiter
                         ; MUST be present at this position in the presented
                         ; order

      required         = [qual] "{" 1*avp-spec [ "/" 1*avp-spec ] "}"
                         ; Either the AVPs before OR after the "/" delimiter
                         ; MUST be present but can occur in any order

      optional         = [qual] "[" 1*avp-name "]"
                         ; The avp-name in the 'optional' rule cannot
                         ; evaluate to any AVP Name which is included
                         ; in a fixed or required rule without the 
                         ; alternative operator

This allows the syntax Jaakko proposed, but does it in the proper level in
the grammar, IMO. Also this grammar is backwards compatible with the
existing command definitions.

I don't see why allowing alternatives would make it harder to determine
whether a Diameter application is supporting a given AVP or not. An AVP is
supported if it is present anywhere in the command definition. The
alternative places additional flexibility to when one of the alternative AVP
(sequences) can be left out, though.

Additionally, in the example above, if both Session-Id and User-Name are
included, the receiver should pick one (maybe the one listed first in the
command definition), and should consider the other as an optional AVP.

With regards,

	Jarno

Erik Guttman wrote:
> Jaakko,
> 
> > The section 3.2 "Command Code ABNF specification" contains the ABNF
> > specification which must be followed when contructing 
> Diameter Command
> > Codes. 
> 
> This is intentional.  Command codes are terminals in Diameter 
> messages.
> I can't say an AVP is either this or that.  
> 
> > This is very restrictive and does not allow enough flexibility when 
> > defining command codes and therefore it is proposed that the 
> > alternatives is included. 
> 
> Restrictiveness in a type system is good.  It makes it clear what you
> require.
> 
> Let's say we get things wrong and have to revise a particular diameter
> application.  We just create new AVPs and commands as necessary.  
> Backwards compatibility is assured precisely **because** we have been 
> very strict and very clear about what AVPs mean.
> 
>   First version                Revised version
>   -------------                ---------------
>   Application A                Application B
>      Command A1                   Command A1
>         Avp A11, A12, A13            Avp A11, A12, B13, B14
>      Command A2                   Command B2
>         Avp A21, A22                 Avp B22
>      etc.                      etc.
> 
> Note the revised version 
>  - has a new application id
>  - will reuse command IDs, if possible, but may replace them (A2->B2)
>  - will reuse AVP ids if possible, but may replace them (A13->B13),
>    remove them (A21-> not supported) or invent new ones (A1 uses B14).
> 
> The result of your change would be much more complicated rules to
> determine if an AVP was supported for any given application.  These
> rules would get ever more complex as we revised the application.
> Consider if each AVP in the 'first version' referred to possibly many
> variants.  This aliasing complicates revision, interpretation and
> reasoning about the specification.  
> 
> I say KISS ('Keep It Simple Standards-cowboys!')
> 
> > It does not contain a possibility to use the alternatives (see
> > RFC2243, section 3.2) when defining the AVPs included into 
> the commands.
> 
> The section you refer to describes how to list alternatives among
> non-terminals.  AVP names are currently terminals and I argue they
> should stay that way.
> 
> Erik
>

---

From: Erik Guttman <[email-masked]>
Date: Thu, 25 Oct 2001 11:32:51 +0200 (MET DST)

Jarno,

> AVP2 being defined elsewhere.

This does complicate things.  A rule that says "AVP1 is required" is
less complicated than a rule which says "'either AVP1 or AVP2' is required."

> An alternative to the whole proposal is that two different commands are

This is the best argument for this feature.  Namely, if you have several
options ( A / B), (C / D), you'd have to define 4 different commands
for each combination and say any of them would do.  That's ugly.

For this reason, I reluctantly support the proposal.

> Modified rules could be like this:

This would require a rewrite of all Diameter specs.  This is not only
editorial work.  It would require quite a bit of technical review to
make sure it remained equivalent to the old representation.

> command definition), and should consider the other as an optional AVP.

No.  A rule which requires a choice of A or B in a fixed position
does not imply that the choice not taken is an optional AVP.  This
would require an additional rule.

Erik