[XCON] [BFCP] Grouped attributes

[Miguel Garcia <Miguel.An.Garcia at nokia.com>]

Hi:

On reviewing the BFCP draft,
http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-03.txt

I found that it is hard for an implementation to parse some attributes 
that come in a "block". Take for example, the FloorInfo message format 
(Section 5.3.6):

   FloorInfo        =       (FIXED-HEADER)
                            [TRANSACTION-ID]
                            (USER-ID)
                            [FLOOR-ID]
                         *( (FLOOR-REQUEST-ID)
                            [BENEFICIARY-ID]
                            [USER-DISPLAY-NAME]
                            [USER-URI]
                           *(FLOOR-ID)
                            [HUMAN-READABLE-INFO]
                            [PRIORITY]
                            (REQUEST-STATUS)      )
                            [NONCE]



There seems to be a block of attributes, enclosed in a parenthesis, that 
come as a collection. This block is:

                         *( (FLOOR-REQUEST-ID)
                            [BENEFICIARY-ID]
                            [USER-DISPLAY-NAME]
                            [USER-URI]
                           *(FLOOR-ID)
                            [HUMAN-READABLE-INFO]
                            [PRIORITY]
                            (REQUEST-STATUS)      )


This block of attributes can be repeated several times, and can indeed 
contain attributes that are optional, or repeated.

From an implementation point of view, it is not that easy to parse all 
these optionalities, repetitions, and blocks. I guess you are basically 
trying to define a hierarchy of attributes here.

It came to my mind that RADIUS seems to have the same problem, problem 
that has been solved in Diameter by created a so-called Grouped 
attribute, which in essence is an attribute that contains other 
attributes. Since a Grouped attribute is an attribute, it follows the 
TLV model, with the only note that the Value is a sequence of attributes 
(each one following also the TLV model).

So I was wondering if BFCP could adopt the same model and define Grouped 
attributes. As far as I know this affects the block that I highlighted 
above, which is used in FloorInfo and another similar block (with less 
attributes) defined in FloorRequestInfo.

If this is acceptable, FloorInfo would have the following structure:


   FloorInfo        =       (FIXED-HEADER)
                            [TRANSACTION-ID]
                            (USER-ID)
                            [FLOOR-ID]
                          * (FLOOR-REQUEST)
                            [NONCE]


And then FLOOR-REQUEST would be defined as:

           FLOOR-REQUEST =  (FLOOR-REQUEST-ID)
                            (REQUEST-STATUS)
                           *(FLOOR-ID)
                            [BENEFICIARY-ID]
                            [USER-DISPLAY-NAME]
                            [USER-URI]
                            [HUMAN-READABLE-INFO]
                            [PRIORITY]

Note also that I have collected all the mandatory attributes at the top, 
as this will also help parsing.

Similarly, FloorRequestInfo would be:

   FloorRequestInfo =     (FIXED-HEADER)
                          (TRANSACTION-ID)
                          (USER-ID)
                          [BENEFICIARY-ID]
                          [USER-DISPLAY-NAME]
                          [USER-URI]
                       1* (FLOOR-REQUEST)
                          [NONCE]


Is this proposal acceptable? Comments?


    - Miguel

--
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon