Subject: RE: [AAA-WG]: One basic question

From: "Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)" <[email-masked]>
Date: Wed, 16 Jan 2002 17:25:50 +0200

Hi,

During parsing I do not have to know what it means. But I have to know
whether the length that I have received is correct or not. For example,
if the data type field is present, if a ill-formed Diameter message
arrives, with an AVP of data type Integer32 and the length of the AVP as
100, I know immediately what to do with the message according to my
policy, and I do not need the dictionary access at all. 

"So, Let's say you do get an OctetString.  What is it?  Username?
Password?
Credit Card number?"

The parser do not have to know what it exactly means. The handler knows
whether it means a Username etc. For this the handler may use any means
and only one of them is maintaining a dictionary. By dictionary if you
are referring to the dictionary described in
"draft-ietf-aaa-diameter-api-01.txt", teh AVPDescriptor does not contain
any extra information from the AVPHeader than the data type. And if the
data type is also present in the header the dictionary can be avoided.

So the data type field is not for display purposes.

Regards,
Kishore

-----Original Message-----
From: ext David Frascone [mailto:[email-masked]]
Sent: 16. January 2002 17:06
To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki)
Cc: [email-masked]
Subject: Re: [AAA-WG]: One basic question

> There are two aspects to this.
> 
>     1. Parsing the Diameter message.
>     2. Handling/Serving the Diameter message.
> 
> If an implementation has to access the AVP dictionary for each AVP
that
> is present in the message in order to parse it and validate it, are we
> not losing on efficiency. During handling the message the dictionary
MAY
> be required. If it is required the imlementation searches for the
> descriptors of the AVPs which it is interested in the message rather
> than ALL the AVPs.
> 
> "What could you do with a type that
> you couldn't do with the AVP code?"
> 
> So I could parse the message without accessing the dictionary. It is
not
> just the question of debugging information but a lot more than that.

I disagree.  You will know the format of the data's syntax, but not what
it
means.  (Basic Syntatic-vs-Symmantic problem)

So, Let's say you do get an OctetString.  What is it?  Username?
Password?
Credit Card number?

Since you can't know what the data *is*, you have to have a dictionary 
anyway.  So, since symmantic defination has to happen somewhere, there
is
no need for the overhead of the syntactic definition in the AVP.

As far as parsing goes, you already know the length of the data, which
is
all you need to parse it.  Why would you need to know it's type,for
anything
other than display purposes?

-Dave

---

From: David Frascone <[email-masked]>
Date: Wed, 16 Jan 2002 09:37:14 -0600

> policy, and I do not need the dictionary access at all. 

So, you simply want the type there to be able to detect invalid lengths
of avps?  Is there any other benefit to having it present?

> data type is also present in the header the dictionary can be avoided.

By dictionary, I mean any internal definition you use to say that 
AvpCode 2 is a User-Name.  In RADIUS, it was called a dictionary.

I'm assuming that by "handler" you mean the application that is parsing
the message.  Since *something* has to maintain a dictionary to parse/handle
the message, why do you want to add that redundant information to the
protocol on the wire?

<sarcasm>We could always just transmit the data in XML, and get rid
of the dictionary all together.</sarcasm>

So far, I only see two reasons to add the field:

  o  To try to detect invalid Diameter messages.  (The space could
     probably better used to hold a simple magic number, i.e. 0xdeadbabe)
  o  To add in displaying the data for debugging.

I do not think either of these is worth adding redundant information to
the protocol on the wire.

-Dave