XCon minutes, March 20^th

Dave Morgan – meeting scribe

Agenda bashing – Adam Roach

Status – BFCP is in RFC, Framework document finished last call, data model close to jelled

Conference event package being discussed

Conference control protocol will be addressed after data model last call

Common conference data model, -04 version– Oscar Novo

Covered small changes in the data model from previous versions – no comments

Open issue – Policy

Gonzalo Camarillo - proposes nothing in the data model

Mary Barnes - policy part of data model

Dave Morgan – agree with Mary, just read and write functions in data model

Gonzalo – if we have anything in, it could complicate what we want to do later, anything we do could influence common policy, haven’t decided semantic or syntactic approach yet

Henning Schulzrinne– danger is merge or conflict problems, when we want to have complicated policy we could have a problem, look at what was done in Simple, rules are additive, how the data types work. Make it extensible data. Referred to discussions in SIMPLE. Worried about merging, what happens when a fancy rule is created?

Adam – wants to do this all in one place, not sure if inside or outside is better. But more natural fit for policy in the data model, in the same place

Gonzalo – propose a different draft, could be an extension of this draft to capture policy

Simon Pietro – Do we need to work on policies in XCON? Other people have proposed XACML? Avoid reinventing policies. People have been doing this for many years. Proposed an example on the mailing list.

Mary Barnes – OK with removing it for now and solving with an extension

Henning – OK with a placeholder which says you can insert it here. Has a PhD working on ontologies. Worried about policies because if something unexpected shows up it’s a big deal.

Roni Even – would like to see role described but no semantics described.

Oscar – can define roles inside extension

Gonzalo – would rather think of all policy separate, doesn’t see a need of defining roles before addressing roles. Discussion with Roni. Why define anything that has no semantics associated with it.

Mary – Roles useful for the policy but useful for other functions as well.

Alan – What if we want to ask who’s in charge of this conference? Get an operator on the line. The roles are a label for humans

Gonzalo – I don’t have a problem if it’s a label

Mary – Framework and Use Cases document use the role function

Roni – data model doc should say you need to extend to include roles and policies

Gonzalo – what do we write in the data model

Roni – would like to keep role definitions

Adam – 1) keep the list of roles in the data model without defining semantics

2) As a separate effort but part of separate XML doc define the permissions associated with operations that can be performed on the data

Oscar - Moving on

Controls

Dave Morgan – keep the basic set, basic active talking speaker, not 3x3 layouts

Gonzalo – happy with keeping it, someone can define extensions

Adam Roach – fine with document staying as is. After this we are moving on to the operations and we’re not going back to the data model

Centralized conferencing using MSRP-03 – Mary Barnes

MSRP provides a valid proof point for the general model

Changes since -02, text around create join, delete

This document does not impact core MSRP document

Miguel Garcia – have a problem with document, don’t know what it is really trying to say, nothing specific to MSRP.

Mary - right, it is transparent to the framework. MSRP was not in the scope of the framework

Miguel – This should go into the framework as a use case, this is nothing new

Mary – It’s an informational document

Miguel – information document has to be valid to the industry

Mary – Other people might find this useful

Miguel – Should put sentences into the framework to capture validity of MSRP in the framework

Mary – it has examples to show people, like the BLISS discussion

Miguel – my view was this was not in the scope of the framework. The problem is the framework tries to be agnostic for protocol, but in essence it’s SIP and that covers MSRP

Aki Niemi – Agree with Miguel, SIMPLE does the protocol details, Xcon should do the hard stuff, roles and affiliations. Probably contains useful information, but more appropriate for consulting services.

Adam – Thinks a document of this nature is quite useful, despite you can do all of this, there is enough confusion that people are going to other working groups and doing text conferencing

Gonzalo – If there is an interop problem then this is useful, otherwise it’s not

Mary – we don’t have a clue if we have an interop problem

Gonzalo – doesn’t see it useful to create documents of tutorial nature

Mary – Thought MSRP was not in the scope of the framework

Adam – The framework is out the door, pulling it back is a mistake. This is a bad fit for the framework

Gonzalo – proposes doing nothing at all – not putting it in the framework

Roni – my expectation should not have 2 user interfaces to create a conference.

Mary – the point was to implement another media type and you can do MSRP with the framework

Roni – can do XMPP, doesn’t matter

Mary- could make this more general and say MSRP is a general example

Way forward – will try and clarify the scope of the document. Again another use case for XCon to validate the framework

Roni – We don’t say XCon is for a specific signaling protocol

Mary – We will modify to use MSRP as an example

XCON URI -01 Mary Barnes

URI schema for conference object identifier

Changes since -00

Guidelines for mapping identifiers

Text originally in framework, moved to a separate document

This text needs to be somewhere

Would like to get this as a work group document

Oscar – this is an integral part of the data model. Both documents are aligned now with version -04 version which has the URI defined. We have not done the IANA registration

Mary - could fold this into the data model, or could stand separate

Henning – unusual to have IANA in a separate model

Mary – could put it in the data model

Henning – don’t like little documents running around, problem with chain of references, updating multiple documents

Adam – heard people say put it in the data model, and others say not to. Any objections to put it in? (there were none)

Adam – we will merge the two documents (this into the data model)

XCon User Identifier -01. Mary Barnes

changes since -00

Reviewed the mailing list item.

Adam - Will pull into the data model as well, no objections.

Roni – Xcon event package extensions

Complements work in data model and complements conference event package

Overcome 4575 Sipping conference event limitations in the Xcon data model. Here are our three options

1) Extend RFC 4575 with a new Mime type, or 2) change the data model to keep compatibility with 4575 – not clean from data model perspective, or 3) define a new event package

Adam – preference is #1

Roni – just means the server will have to support both elements. Roni pointed out that the data model draft says it’s informational

Adam – data model itself is not supposed to be informational, it will have to be standards draft

Roni – it will need to be changed, for example dealing with current speaker notification, have to poll the data model, proposed status elements in the event package

Oscar – these status elements should be in the data model

Roni – Way forward agreed, status elements should be kept in the data model. Has to take into account Cullen’s feedback on the list.

General Discussion – Led by Adam

Adam – will need to be clear with further milestones in the group

Gonzalo – we are not to work on conf control protocol yet, why was XCAP dropped, can we get a summary on the mailing list.

Adam – Will attempt to dig it out. Short answer, the group converged on a semantic approach and that was a syntactic approach

Mary – that was not relevant to the work we were doing at that time

AJOURNED