Re: [bfcpbis] More comments on RFC 4582

[Tom Kristensen <[e-mail]>]

On 16/04/2012, Gonzalo Camarillo <[e-mail]> wrote:
> Hi,
>
> below you can find another old email with more comments on RFC 4582.
[...]

I've commented the issues inline below.
The two new error codes is included in the upcoming draft version.

-------------------------------------------------------------------------------------
> [...]                                            I got the action
> point to list the things that could be fixed in a potential revised
> BFCP spec. These are the contents of my notes. Of course, if someone
> knows of more issues, please let us know:
>
> o When a user performs a third-party floor request the beneficiary of
> the floor is not informed when the floor is granted. This may not be
> a problem because endpoints using third-party floor requests probably
> have different means to get in synch but we may want to add some text
> about this.

Tom: Not sure this is needed, as it is stated in Section 2 that:
"... The protocol between a floor participant and a media participant
 (that are not colocated) is outside the scope of this document".

> o We do not have errors for an unsupported version of the protocol or
> for wrong message length. We do not have a general error either.

Tom: Unsupported version is handled in the current version of the
rfc4582bis draft. The other two is added to the upcoming version,
i.e. Incorrect Message Length and Generic Error.

> o When we get more experience on queue management from real
> deployments, it would be nice to explaining it further in the spec.

Tom: I have no knowledge of queue management from deployments.
Does anyone else out there have any deployment experience? If not,
we don't really have much to add at present.

> o UserStatus
>
> UserStatus =   (COMMON-HEADER)
>                  [BENEFICIARY-INFORMATION]
>                1*(FLOOR-REQUEST-INFORMATION) -> remove the 1
>                 *[EXTENSION-ATTRIBUTE]

Tom: Was already correct in RFC4582, outdated note I presume.

> o A message may need to be longer than the maximum message length
> supported by the protocol

Tom: We've solved the fragmentation issue. No demands voiced for length
exceeding the maximum message length for reliable transport voiced in
BFCPbis.

> o A rather small number of typos

Tom: A couple of typos fixed in both current and upcoming version of
rfc4582bis. Reviewers might find more!
-------------------------------------------------------------------------------------


-- Tom

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/