Subject: Re: [XCON] Proposed small fixes to BFCP

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 May 2006 10:00:34 +0300

Hi,

here you have a new revision of the draft addressing the issues I 
discussed in my previous email:

http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-07.txt
http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-06-to-07.html

Note that this revision will not be submitted until, as Adam pointed 
out, we discuss with our AD.

Cheers,

Gonzalo

Adam Roach wrote:
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 May 2006 15:40:15 -0700

Let me know if anyone see significant problems with these changes. In  
the mean time I will work with authors and RFC editor to figure out  
best way to get them done.

Cullen

On May 25, 2006, at 12:00 AM, Gonzalo Camarillo wrote:

> Note that this revision will not be submitted until, as Adam  
> pointed out, we discuss with our AD.
>
> Cheers,
>
> Gonzalo
>
> Adam Roach wrote: