Subject: [Dime] Support for Class AVP mandatory in session based apps?

From: Anders Kristensen <[email-masked]>
Date: Fri, 09 Jun 2006 18:43:03 -0400

The Class AVP defined in the base Diameter spec allows a server to pass 
a "cookie" to the client and receive it back in subsequent requests from 
the client to the server belonging to the same session.

However, a number of applications do not explicitly list the Class AVP 
in the definition of session-creating answers or in mid-session 
messages. This is true, for example, for the Credit-Control-Answer in 
RFC 4006 and for the AA-Answer in 3GPP TS 29.209 (IMS's Gq app). While 
the Class AVP is not explicitly listed the grammars of both these 
answers do include *[AVP] so at least according to the grammar it's OK 
to include the Class AVP.

My question is whether a client that does not honor the Class AVP in 
these cases can claim to be standards compliant. In my view it would be 
preferable if support for the Class AVP was required for all session 
based apps unless possibly if an application explicitly says otherwise 
(and not just in the grammar).

Thanks,
Anders

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 12 Jun 2006 10:01:37 -0400

... resending ....

Anders,

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Friday, June 09, 2006 6:43 PM
> To: [email-masked]
> Subject: [Dime] Support for Class AVP mandatory in session based apps?
>
>
[TOLGA]I believe the point is that server MAY include Class AVP and in such
a case it MUST be present in the subsequent messages. If server chooses not
to make use of Class AVP, it won't be used in subsequent messages. I don't
know what is the best way to convey this information in ABNF. Like you have
said, *[AVP] allows pretty my much anything but [Class] may have been used
as well.
> (and not just in the grammar).
[TOLGA]IMO, such a client is violating the specification. For required
support of Class AVP, if what you mean is that servers SHOULD make use of
it, IMHO it is better to leave that decision to the server. If what you mean
is that Class AVP should be present in subsequent messages if server
includes it in the answer, I agree with you -but isn't this what 8.20 is
already saying?-

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 12 Jun 2006 08:41:42 -0400

Anders,

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 12 Jun 2006 22:38:32 -0400

Tolga,

Inline...

Tolga Asveren wrote:

> a case it MUST be present in the subsequent messages.

Right, that's what I'd like to be the answer too. It's not spelled out 
sufficiently in the spec, though.

  If server chooses not
> know what is the best way to convey this information in ABNF.

Well, if "*[Class]" is listed explicitly in the definition of the 
relevant messages there can't be any doubt that it's allowed. The ABNF 
can't and shouldn't go beyond that.

  Like you have
> [TOLGA]IMO, such a client is violating the specification.

This is what I'd like to see spelled out in the base spec.

  For required
> includes it in the answer, I agree with you -but isn't this what 8.20 is

Well, yes it is but then when this is reinforced by explicitly including 
*[Class] in the grammar of some apps but leaving it out in others it 
invites the interpretation that support is predicated on the AVP being 
listed explicitly. Or so it seems to me. I'd be surprised if all clients 
of the credit control app supports the Class AVP.

Thanks,
Anders