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

From: [email-masked]
Date: Thu, 25 Oct 2001 12:49:33 +0300

Erik,

You wrote:
> > 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.
> 
> 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."
> 

I agree, on the level of a single rule it is more complicated...

> > An alternative to the whole proposal is that two different 
> commands are
> > defined.
> 
> 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.
> 

... but having a separate command for each combination will likely be more
complex on the level of the Application specification.

> For this reason, I reluctantly support the proposal.
> 

Great.

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

I though that the rules I presented were backwards compatible. The current
way of placing each AVP in it's own brackets is still covered by the
proposed new grammar rules. Hence the grammar rules in the Base Diameter is
the only place that needs to be changed.

> > 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.
> 
> 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.
> 

At the least the "optional" rule's comment should be modified to allow
specifying an AVP both as an alternative and optional.

	Jarno

---

From: Erik Guttman <[email-masked]>
Date: Thu, 25 Oct 2001 14:01:33 +0200 (MET DST)

Jarno,

> I agree, on the level of a single rule it is more complicated...

It gets worse the more options you have.  If there are 3 rules 
which have 3 options each, there are 9 valid combinations.  Are
all valid?  Things get ugly if the options aren't independent.
Further, more options make interoperation harder to verify and
protocol implementations more complex and less likely to be 
hardened.

> complex on the level of the Application specification.

Yes.  But let's resist (wherever possible) the introduction of 
more than one way to do anything.

> the only place that needs to be changed.

If so - why do you want to introduce this change?!?  To ease the way
for protocol complexity in the future?  :/

Erik

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 25 Oct 2001 07:23:42 -0700

After following this thread, I tend to agree with Erik. Adding this feature has
unknown ramifications in the drafts, will require more editorial work, and it is
still unclear to me what applications would benefit from this feature.

So, unless this is considered a bug, we had agreed not to add new features many
moons ago. If there is a known bug that requires this feature, then please point
it out.

Thanks,

PatC