Subject: [AAA-WG]: List data type discussion

From: Erik Guttman <[email-masked]>
Date: Thu, 10 May 2001 10:46:25 +0200 (MET DST)

Under discussion, still not finally resolved is whether we should have
a base 'List' data type, which would essentially allow 'N' identical 
items to follow.  We have no concrete examples of where this would be
useful. 

There are issues with the List data type:

(1) Length ambiguity

    In this case of a List of 'N' Integer32 values, an AVP length would 
    be the following # of bytes:

      8 [+ 4 (if 'V'endor ID included) ] + 4 * N 

    By observing the AVP length (and whether the 'V' bit is set), the
    receiver can calculate how many Integer32 values follow.  This would
    allow the efficient encoding of the data 

      [Header] [Int32-0]...[Int32-(N-1)]

    In the case of data types OctetString, Address, Group and List
    it will not be possible to determine how many data items follow
    simply by observing the AVP length field.  To make it possible to
    parse individual items in the list, we need to separate them into
    individual units of {Length,Data} or perhaps better yet 
    {AVP header,Data}.  

(2) Why use a List AVP at all?

    But if we are going to do that, what is the use of the List data 
    type?  Where do we gain by having, say,

       <Some-Command> ::= <Diameter Header: ???>
                          { Origin-Host-List }
 
       Origin-Host-List AVP = 1* Origin-Host AVP
       Origin-Host AVP has type Address 
         
    which leads to the encoding of:
        
       [Origin-Host-List AVP header]
       [Origin-Host AVP Header 0]
         Address 0
            ...
       [Origin-Host AVP Header N-1]
         Address N-1

    instead of just having 0 or more Origin-Host AVPs in the message:

       <Some-Command> ::= <Diameter Header: ???>
                         1* { Origin-Host }

    Using the same definition of Origin host as above,

       Origin-Host AVP has type Address 
    
    This leads to the encoding:

       [Origin-Host AVP Header 0]
         Address 0
            ...
       [Origin-Host AVP Header N-1]
         Address N-1

    Which is exactly what we had before, but there is no 'wrapping'
    List AVP.  

    What we gain here is that there is a definite group - one will
    be able to transmit a 'column' of data, like a SMIv2 'SEQUENCE OF',
    a facility our grammar currently lacks.  

The question remains - do we need List?  Let's try to reach final
working group concensus on this now.  If in favor of the proposal,
please send concrete examples of why it is needed.

Thanks,

Erik

---

From: David Frascone <[email-masked]>
Date: Thu, 10 May 2001 09:24:49 -0500

Actually, I don't remember hearing a compeling argument on why Grouped
AVP definitions had to be static.  I did notice several people who thought
they should be left open, like the Diameter message itself.

Did my delete finger just go crazy, or did no one really want statically
defined group AVPs?

-Dave

---

From: David Spence <[email-masked]>
Date: Wed, 23 May 2001 17:27:38 -0500

I think that our new broader definition of the Group type would accommodate
lists as well.  If I want to define a Foo-List AVP that would contain a list
of Foo AVPs, I simply state that the Foo-List AVP contains * {Foo}.  So we
can now define lists if we ever want to.  :-)

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.