Subject: RE: [Dime] Mistakes in standards?

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 24 Dec 2006 02:12:48 -0800

Hi, 
 
I've found few mismatches of command and AVP definitions, both in base
diameter and 3GPP standards. Two examples:
- In rfc 3588, section 6.11 defines:

   <Vendor-Specific-Application-Id> ::= < AVP Header: 260 > 

                                     1* [ Vendor-Id ]

                                     0*1{ Auth-Application-Id }

                                     0*1{ Acct-Application-Id }

This definition contradicts the definition of grouped AVP (section 4.4),
since optional AVP comes before required AVPs.  

I agree that the ABNF is wrong, but not in the same way.  Although I'm
hardly an ABNF expert, it seems to me that "1* [ Vendor-ID ]" and "{
Vendor-ID }" are semantically identical.  OTOH, the ABNF seems to allow
instances of both the Auth-Application-Id and Acct-Application-Id AVPs
in the same Vendor-Specific-Application-Id AVP, but the textual
description of the Vendor-Specific-Application-Id AVP seems to forbid
this: "Exactly one of the Auth-Application-Id and Acct-Application-Id
AVPs MAY be present."  I say that it "seems to forbid" it because I find
this sentence very difficult to parse.  I'm guessing that it means
either "Exactly one instance of either the Auth-Application-Id or
Acct-Application-Id AVPs but not both MUST be present."  or "Either the
Auth-Application-Id or the Acct-Application-Id AVPs but not both MAY be
present."  The latter interpretation doesn't make a lot of sense,
though, because you could end up with a Vendor-Specific-Application-Id
AVP without an application ID!  In any case, I think that the use of the
alternative syntax (RFC 4234, section 3.2) would be much more
appropriate here.

... 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 26 Dec 2006 16:12:08 -0500

Hi Glen,
> This definition contradicts the definition of grouped AVP (section 
> 4.4), since optional AVP comes before required AVPs.  
>
>  
>
> Vendor-ID }" are semantically identical.  OTOH, the ABNF seems to 
> allow instances of both the Auth-Application-Id and 
> Acct-Application-Id AVPs in the same Vendor-Specific-Application-Id 
> AVP, but the textual description of the Vendor-Specific-Application-Id 
> AVP seems to forbid this: "Exactly one of the Auth-Application-Id and 
> Acct-Application-Id AVPs MAY be present."  I say that it "seems to 
> forbid" it because I find this sentence very difficult to parse.  I'm 
> guessing that it means either "Exactly one instance of either the 
> Auth-Application-Id or Acct-Application-Id AVPs but not both MUST be 
> present."  or "Either the Auth-Application-Id or the 
> Acct-Application-Id AVPs but not both MAY be present."  The latter 
> interpretation doesn't make a lot of sense, though, because you could 
> end up with a Vendor-Specific-Application-Id AVP without an 
> application ID!  In any case, I think that the use of the alternative 
> syntax (RFC 4234, section 3.2) would be much more appropriate here.
>
> ...
>

I agree. I think we can expand the proposed solution in Sec 2.6 of the 
errata to include this suggestion.

regards,
victor