Authenticating a user -- is this really useful? We have the necessary
tools in conditions. This will be removed in the next draft.

Meta Policy -- many conditions are defined -- should there be a separate
document? Simplifies conference policy document, but many conditions
would be repeated in both documents. Should there be separate actions
defining read access?

<time> vs <validity> - these are separate things -- is it OK if a rule
is only valid for part of a conference lifetime?

Providing anonymity -- should there be rules allowing specific users to
be anonymous?

Is there a difference between <anonymous> and <pseudonym>? Do we need
both? The focus can generate an anonymous attribute on behalf of the
user, and other users will know that an anonymous user is present. We're
providing pseudonym-ity anyway -- true anonymity is hard to provide,
because someone (ISP, focus, etc.) knows the identity in order to connect
the user to the conference at all.

External lists -- what does it mean for an <id> element to carry an
XCAP URI? Should the use of external lists be more explicit (<external>
element or "external" attribute)?

Unauthenticated Identities -- do we need to list users that need to be
authenticated? "anyone who claims to be bob@example.com can join the
conference." But this isn't needed to identify people who come through
gateways (PIN codes, etc. would work). Why do we want to have policies
controlling unauthenticated identities at all? Why would we limit the
number of unauthenticated participants who all claim to be an allowed
participant in the conference? Authorization without authentication is
just silly. Does policy matter for inactive (listen-only) participants?

Floor-id uses floor URI -- needs to reflect current floor control
protocol.

1030 - 1130  Binary Floor Control Protocol (BFCP)
             Gonzalo Camarillo (60 minutes) draft-ietf-xcon-bfcp-00.txt

This revision adds context text, supports third-party floor control,
has clarifications, and incorporates comments from the mailing list.

Replay protection -- implement in protocol, or continue to rely on TLS? We
implemented integrity in the protocol -- should we rely on TLS for both
replay protection and integrity? Security antennae will quiver if we do
only one... we will do both, or neither.

Do we need more than a simple flag for privacy (it's all or nothing
now) -- disclose identity to chairs, but not to others? - Why is this
request-by-request? Rohan asked for this in the interim meeting,
but there's already a loose coupling between identities and floor
requests. But this mechanism doesn't help speakers be anonymous -- the
next speaker is probably the one who requested the floor, anyway. This
is feature creep in a small protocol. How can you identify a user at
all? There is text in the draft in how to do this correlation. If a
user requests the floor anonymously and then performs an action that
is visible, there's no meaningful anonymity anyway. If you want to
be anonymous, be anonymous all the time. This is complexity and not
needed. Is this forward secrecy, or "we'll never know who that was"? There
are privacy issues lurking somewhere in here, especially if people can
see requests (when not using TLS). If you're speaking in a voice call,
you're giving up your anonymity on your own, and we need to make sure
we're not putting a legal onus on a chair to preserve your anonymity.

Can a server add mandatory TLVs? We would need a capability negotiation
mechanism, or a way for clients to complain about unknown TLVs.

Does CPCP allow users to authorize 3rd party floor requests?

Can we use the BFCP fixed header with non-TLV payload types (XML
notifications, etc.)? This is too much feature creep for a very simple
protocol -- we should be removing features, not adding this one.

Can users modify ongoing floor requests? Do we need this feature? Nope.

Is BFCP a transport or a payload type in SDP? Payload type would
require MIME registration. Is there a working group where someone
might care? Gonzalo will present this in AVT. Is this control, or
application? It's application, and the applications guys recommended
that we not start a new top-level registry.

Floor-stream mapping for non-CPCP clients? Label the media streams? Add
floor-ids to all the SDP m-lines? Or do something else? Will be
synchronized with the media policy team.

   CPCP over MSRP -- Tim Melanchuk

Some discussion of non-XCAP protocol for CPCP, providing message
transport and the messages themselves. These could be XML over TCP +
TLS, leveraging SIP session establishments. MSRP is defined for instant
messages but could be used in other contexts.

Many details to work through -- is there a need in XCON?

If you were using XCAP for this, you could use a URI to refer to policy
pieces -- how would you do this using MSRP? Let's not tunnel XCAP over
MSRP, okay?

Why reuse SIP session establishment? Offer/answer, same SIP URIs as rest
of application.

Like this idea, has been proposed for video applications in the past,
but may not be right here. Why is notion of a session needed? This
is a transactional problem. SIP is really good at rendezvous problem,
but that's not what we're doing here, either.

Is this a general RPC mechanism? I vote "no".

We need to start from requirements and not just have ideas. What is the
problem this proposal solves?

Reusing SIP session establishment really is valuable, and "MPC" looks
a lot more like a session than this example.

Support this approach, because this is a better RPC mechanism than XCAP.

No, if you want RPC, do SOAP!

XCAP was chosen as one way, among other ways, to transport CPCP. It's
not the One True Way.

Keep on working on this idea -- the more, the merrier.