Subject: data type modifications to DIAMETER

From: "Erik Guttman" <[email-masked]>
Date: Wed, 10 Jan 2001 15:18:52 +0100

As proposed in draft-ietf-aaa-issues-04.txt and 
draft-ietf-aaa-solutions-01.txt section 9.2, I am 
revising the basic data types in DIAMETER.

I do not list all the changes in this document - 
but the implications are the following.

 1. Data type changes:

    Old type        New type
    ------------    -------------
    Address         Address
    Data            OctetString
    String          OctetString
    Time            Unsigned32
    Integer32       Integer32
    Integer64       Integer64
    Complex         Grouped
                    Unsigned32
                    Unsigned64
                    Float32 
                    Float64
                    Float128

 2. Scalar quantities (Ids and so on from AVPs) had Integer32 type. 
    Now they have Unsigned32 type.

 3. String is now one interpretation of an OctetString.

 4. Time is now one interpretation of an Unsigned32 value.

 5. The biggest change is the elimination of the 'Complex' data 
    type.  Now all AVPs have an 'atomic' data type except for
    Grouped.  Grouped takes as its value a list of AVPs which
    have to be included (AVP header and all) in exactly the
    sequence specified.

Implications for DIAMETER implementations:

  The only real change is that Complex data types have been 
  restructured.  Code handling AVPs which were previously of
  type Complex will have to change.

  Code which handled the previous types will be easily mapped
  into the new data types (Integer32 -> Unsigned32, Time ->
  Unsigned32, String -> OctetString)  There are some subtle
  range checking changes to be made (maybe) since scalars are now
  Unsigned32 where before they were Integer32.
  
Rationale:

  See draft-ietf-aaa-issues-04.txt.  In short, there were several
  problems with the basic types used by DIAMETER.  (1) Some were
  interpretations (String and Time) not basic scalars.  (2) Some
  were ambiguous (Integer32 used as an unsigned scalar).  (3) Not
  including basic types (floats, mostly) makes future expansion
  hard.  (4) The types specified were incompatible with SMI and 
  SPPI data types. (5) The complex data type made it hard to
  create a general data model, easily automated parsers and
  general 'sniffers.'  All AVPs should either have atomic values
  or a list of AVPs as their values.  (6) The Grouped-AVP was
  unnecessarily complex. (7) Complex data types required a 'hack'
  for fixing the length of certain data fields (such as using 16
  bytes for addresses where they could be 4 bytes long).  This is
  no longer necessary.

Erik