RE: [XCON] Proposed small fixes to BFCP

["Even, Roni" <roni.even at polycom.co.il>]

Hi,
I looked at the changes suggested by Gonzalo and they make sense to me. Do not see any issues.
Roni Even

> -----Original Message-----
> From: Adam Roach [mailto:adam at nostrum.com]
> Sent: Saturday, April 29, 2006 2:27 AM
> To: Gonzalo Camarillo
> Cc: Joerg Ott; Keith Drage; alan at sipstation.com; XCON
> Subject: Re: [XCON] Proposed small fixes to BFCP
> 
> I was hoping to hear more from working group members before making the
> decision -- but it appears that no one has any comments one way or the
> other on the issue. I'll discuss with our AD and try to determine the
> best way to move forward.
> 
> /a
> 
> Gonzalo Camarillo wrote:
> > Adam, Alan,
> >
> > I would like to, at least, get the "go ahead" from the chairs...
> >
> > Thanks,
> >
> > Gonzalo
> >
> > Gonzalo Camarillo wrote:
> >> Folks,
> >>
> >> while implementing our BFCP stack (the 'running code' part of the
> >> protocol), we have discovered a couple of relatively minor bugs in
> >> the BFCP spec that need to be fixed. They are probably too big to be
> >> fixed thru RFC editor notes. My suggestion would be to remove the
> >> draft from the queue, perform the changes I propose below, and send
> >> it back to the queue. Opinions?
> >>
> >>
> >> Section 5.3.9 defines the ChairAction message. That message can
> >> contain several floors (which belong to the same floor request
> >> operation) but can only provide a single queue position (within the
> >> REQUEST-STATUS attribute) for all of them. We need to be able to
> >> provide different queue positions for different floors (e.g., second
> >> for floor 1 and third for floor 2). In order to do this, we need to
> >> define a new grouped attribute called FLOOR-REQUEST-STATUS whose
> >> definition would be the following:
> >>
> >> Attribute header:
> >>
> >>      0                   1                   2                   3
> >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>      |x x x x x x x|M|    Length     |           Floor ID            |
> >>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >> Attribute ABNF:
> >>
> >>  FLOOR-REQUEST-STATUS =   (FLOOR-REQUEST-STATUS-HEADER)
> >>                           (REQUEST-STATUS)
> >>                           [STATUS-INFO]
> >>                          *[EXTENSION-ATTRIBUTE]
> >>
> >> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute
> >> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'
> >>
> >> The same for the already existing ChairAction message.
> >>
> >>
> >> Additionally, we would define a new grouped attribute called
> >> OVERALL-REQUEST-STATUS, whose definition would be almost identical to
> >> the FLOOR-REQUEST-STATUS attribute. The only difference is that this
> >> one would carry a Floor Request ID instead of a Floor ID. This
> >> attribute would be used within the FLOOR-REQUEST-INFORMATION
> >> attribute, whose ABNF would become:
> >>
> >> OLD:
> >>
> >>    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
> >>                                  (REQUEST-STATUS)              <--
> >>                                1*(FLOOR-ID)                    <--
> >>                                  [BENEFICIARY-INFORMATION]
> >>                                  [REQUESTED-BY-INFORMATION]
> >>                                  [PRIORITY]
> >>                                  [PARTICIPANT-PROVIDED-INFO]
> >>                                  [STATUS-INFO]                 <--
> >>                                 *[EXTENSION-ATTRIBUTE]
> >>
> >> NEW:
> >>
> >>    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
> >>                                  (OVERALL-REQUEST-STATUS)
> >>                                1*(FLOOR-REQUEST-STATUS)
> >>                                  [BENEFICIARY-INFORMATION]
> >>                                  [REQUESTED-BY-INFORMATION]
> >>                                  [PRIORITY]
> >>                                  [PARTICIPANT-PROVIDED-INFO]
> >>                                 *[EXTENSION-ATTRIBUTE]
> >>
> >>
> >>
> >> Then, we would need to add a brief discussion on queues, indicating
> >> that the queue positions in the OVERALL-REQUEST-STATUS attribute
> >> refer to positions in a global queue for floor requests and that
> >> queue positions in the FLOOR-REQUEST-STATUS attribute refer to
> >> positions in a queue for floor requests for a particular floor. Of
> >> course, implementations are free to implement (or provide information
> >> about) one, both, or none of these queue types.
> >>
> >> The ChairAction message would become:
> >>
> >> OLD:
> >>
> >>    ChairAction  =   (COMMON-HEADER)
> >>                   1*(FLOOR-ID)             <--
> >>                     (FLOOR-REQUEST-ID)
> >>                     (REQUEST-STATUS)       <--
> >>                     [STATUS-INFO]
> >>                    *[EXTENSION-ATTRIBUTE]
> >>
> >> NEW:
> >>
> >>    ChairAction  =   (COMMON-HEADER)
> >>                   1*(FLOOR-REQUEST-STATUS)
> >>                     (FLOOR-REQUEST-ID)
> >>                     [STATUS-INFO]
> >>                    *[EXTENSION-ATTRIBUTE]
> >>
> >>
> >> A different issue (more easily fixable than the issue above) is that
> >> the FloorRequest and the FloorQuery messages should carry
> >> 1*(FLOOR-ID) instead of *(FLOOR-ID).
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
> 
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

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