Since I'm taking notes anyway ...  ;-)

-----------------

Session began with a brief discussion of BFCP: After a quick review of open issues no one offered any resistance to WGLC.

Discussion then returned to the current framework draft ...

Issue: Do we need a new/enhanced definition of "focus" -- compared to that contained in the SIPPING conferencing framework? Discussion deferred to tomorrow, pending further resolution of the data/object model.

Issue: "Multimedia stream" is a bad label for the concept described. Resolution: Agreed. Further, the entire construct will be removed pending demonstrated need for a shorthand label for same.

Issue: Data model and template. The current framework proposes the following:

    - Conference-Info type is an umbrella for all conference info (sic).
    - Media pattern is a subtype (or set of subtypes), each registered
      with IANA and used by the Conference-Info type.
    - Template, reservation and instance are data objects of type
      Conference-Info.

Brian's competing model:

    - Template is the top type. It includes all possible conf. info.
    - XCON will define multiple templates and register each with IANA.
    - In order to create a reservation or a conference instance, an XCON
      server needs to apply a separate set of ranges and policy rules
      to one of the standard templates.

Both models assume that

    a) The IANA registry contains (name, RFC reference, XML/XSD schema name) triples.

    b) XCON-aware clients will ultimately be provided with an XML document/object representing the template of interest -- if only by name. For example, a client could ask the conferencing service for the list of templates/conference types supported, then allow the user to select the desired template from that list, then use the selected template to drive the collection of required parameters.

Henning: An XCON client should never have to deal with XML. (Yikes!)
Brian: I think you'll find that the hierarchy that XML provides -- e.g.
    for controls -- will be desirable (to make visible).
Adam: Are you saying that the protocol should not expose the parameters
    (including names) back to the client, or simply not do so using XML?
Henning: Getting a name for a parameter is meaningless unless I know the
    semantics. ... I want to have a model where each individual protocol
    element is an object ...
Adam: Off track. Let's come back to this discussion later.
Some 30+ minutes later, we moved on.

Issue: Recurring conferences. Consensus/resolution:

    - We must support recurring conferences and scheduling thereof.
    - We will do so by heavily leaveraging iCal.
    - We must support distinct URIs for instances and the series.
    - When an XCON client makes a reservation OR wants to specify a
      sub-ranged of a recurring meeting, it uses an iCal object
      to specify timing/recurrence.