Subject: Fw: diameter grammar proposal

From: "Erik Guttman" <[email-masked]>
Date: Wed, 10 Jan 2001 16:25:17 +0100

Dave,

>My problem is:  If you list all of the "optional" AVPs, then it seems like
>if an AVP is received that is not on the "optional" list, it is an error.
I
>think listing optional AVPs is problematic.

My solution to this problem is to allow the token 'AVP' to stand for
*any* AVP.   In the example:

>>      Example-Command ::= <DIAMETER-Header: 9999999>
>>                         { User-Name *Host-Name }
>>                         * [ AVP ]
>>                         ? < Integrity-Check-Vector >
>>
>>    The command defined by the preceding grammar MUST begin with a
>>    DIAMETER header, with the command code Id set to 9999999.  There
>>    follows a User-Name AVP, zero or more Host-Name AVPs and zero or
>>    more arbitrary other AVPs (but not User-Name, Host-Name or
>>    Integrity-Check-Vector AVPs).

Here 'AVP' could be anything (vendor specified or otherwise)  BUT the
requirement is that the optional AVP rule cannot include AVPs otherwise
specified in REQUIRED or FIXED fields.  That allows you to write rules
for AVPs which can only occur once, or have to occur in a particular
sequence.

Erik

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 10 Jan 2001 07:33:15 -0800 (PST)

>I propose the following section be added to the DIAMETER base spec.
>This will allow us to specify DIAMETER in a more formal way.  This is
>unfortunately not as formal as a BNF would be, but DIAMETER messages
>allow for arbitrary ordering of many elements.   Still, we need to
>be able to specify that some elements may appear only once, and some
>have to appear in fixed positions.  I believe this grammar suffices
>to do this.  Please send comments.

Here are my two cents.

I actually really like Erik's proposal. For the most part, the dictionary and
how messages are defined in the protocol specs are two separate issues, and I
am not sure why we've decided to combine the two. 

The proposal below is much richer than today's spec, since it allows DIAMETER
to defined the message set, while providing information on the number of
AVPs that may (or MUST) be present in the message. This type of information
is present in RADIUS, and is really lacking in DIAMETER.

So here is my proposal. Come out with draft-ietf-aaa-diameter-*00.txt as a WG
work item, with the proposed grammar below. Have the WG work out the details
of data model, and consider whether the message definition in the specs must
follow the accepted grammar. If need be, updated the spoecs as *01.txt.

The reason why I want this done is that there is a bakeoff coming up in 1.5
months, and some of us really want specs to write against. As you know, the
grammar used does not affect the on-the-wire protocol, so this does not affect
the bakeoff.

Comments?

PatC
>
>(Randy, does this hold water?)
>
>Erik
>---------------------------------------------------------------------
>
>1.3 Notation
>
>   The DIAMETER protocol is composed of messages which have three
>   components - a message header, a command code and a set of AVPs.
>   Each message type is distinguished by a single command code.
>   Command are specified using the following notation.
>
>     Command-Code-Name ::= <DIAMETER-Header: #>
>                          { qual AVP }
>                          qual [ qual AVP ]
>                          qual < AVP >
>
>   The symbol # will be replaced by the command Id which is to be
>   placed in the message header.  The symbol AVP MAY be replaced
>   by the names of any specific AVP.  
> 
>   Elements surrounded by less than, greater than '<' and '>' are
>   FIXED in sequence.   For example, the DIAMETER header MUST
>   precede all AVPs.
>
>   Elements surrounded by set brackets '{' and '}' are REQUIRED
>   to be present in the message.  They MAY be in any order within
>   the message provided they do not violate order imposed by message
>   fixed elements in the grammar (which are defined between '<' 
>   and '>' brackets.)
>
>   Elements surrounded by square brackets '[' and ']' are OPTIONAL.
>   AVPs which are listed in this section MAY be included in the
>   message, in any order, provided they do not violate order imposed
>   by fixed message elements in the grammar.  AVPs listed in FIXED
>   or REQUIRED sections MUST NOT be considered OPTIONAL as well.  
>   An AVP required to appear once in one section MUST NOT, therefor,
>   be included as the result of an 'OPTIONAL AVP' rule.
>
>   The token 'qual' can be the following:
>     
>     omitted    One instance of the following entry is required.
>      '*'       Zero or more instances of the following entry are 
>                required.
>      '+'       One or more of instances of the following entry
>                are required.
>      '?'       Zero or one of instances of the following entry
>                are required.
> 
>   Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
>   can be permuted into any order, provided that none of them come 
>   before the Header. 
>
>   DIAMETER messages which violate the grammar defined for the
>   command code are considered malformed and are rejected.  See
>   Section 5.0.

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 10 Jan 2001 18:54:04 -0500

Pat,

> If we were to make the above changes, would you object to this
> ABNF format in the -00 spec?
>

No objections here. As you point out, the bake-off is coming up fast so lets
go with this for the -00 spec.

Regards,
       Mark