XCON

1
XCON

• IETF 66
• March 20th, 2006
• Montréal, QC, Canada

2
Note Well

• Any submission to the IETF intended by the
  Contributor for publication as all or part of an
  IETF Internet-Draft or RFC and any statement made
  within the context of an IETF activity is
  considered an IETF Contribution. Such
  statements include oral statements in IETF
  sessions, as well as written and electronic
  communications made at any time or place, which
  are addressed to
• the IETF plenary session,
• any IETF working group or portion thereof,
• the IESG, or any member thereof on behalf of the
  IESG,
• the IAB or any member thereof on behalf of the
  IAB,
• any IETF mailing list, including the IETF list
  itself, any working group or design team list, or
  any other list functioning under IETF auspices,
• the RFC Editor or the Internet-Drafts function
• All IETF Contributions are subject to the rules
  of RFC 3978 and RFC 3979. Statements made outside
  of an IETF session, mailing list or other
  function, that are clearly not intended to be
  input to an IETF activity, group or function, are
  not IETF Contributions in the context of this
  notice.
• Please consult RFC 3978 for details.

3
Administrative Tasks

• Minute Taker?
• XMPP Scribe?
• Blue Sheets

4
Agenda

5
Status

• BFCP in AUTH48 (will be RFC 4582), along with
  companion MMUSIC BFCP SDP draft.
• Conferencing Scenarios still in RFC Editors
  Queue
• Framework document probably ready for WGLC,
  modulo any changes in data model structure.

6
Status (Continued)

• Need to finalize data model will discuss
  proposal momentarily.
• After data model is handed off to IESG, will
  begin discussing operations to modify conference
  state.
• After operations are identified, will define
  protocol to carry operations

7
BFCP Interop

• University of Naples and Ericsson have
  implemented an interoperable set of BFCP stacks.

8
Data Model
9
Editing Team Proposal

• Key change summarized on mailing list
• Eliminate templates
• Put controls where appropriate in data model
  (e.g. under ltusersgt/ltusergt/ltendpointgt/ltmediagt)
• Allow extensions à la PIDF (e.g. PIDF, RPID,
  PIDF-LO) to describe additional controls
• Change reflected in revised version Oscar sent to
  list on Tuesday

10
Example User Media Control

• Under ltusersgtltusergtltendpointgtltmediagt
• ltfrom-mixer nameAudioOutgtltcontrolsgt
  ltcontrol typesigned-char namegain
  enabletrue gt ltdisplay-text xmllangengt
  Volumelt/labelgt ltvaluegt0lt/valuegt
  lt/controlgtlt/controlsgt
• lt/from-mixergt

11
Example Moderator Media Control

• Under ltconference-descriptiongt/ltavailable-mediagt/lt
  entrygt
• ltpropertiesgtltproperty namemute
  typeboolean enablefalsegt ltdisplay-text
  xmllangengt Mute All Audiolt/labelgt
  ltvaluegtFalselt/valuegtlt/propertygt
• lt/propertiesgt

12
Example Moderator Media Control

• Under ltconference-descriptiongt/ltavailable-mediagt/lt
  entrygt
• ltpropertiesgtltmute enablefalsegt
  ltdisplay-text xmllangengt Mute All
  Audiolt/labelgt ltvaluegtFalselt/valuegtlt/mutegt
• lt/propertiesgt

13
Are We Crazy?

• or does this seem like a good path?

14
Additional Issue Syntax?

• Suggestions have been raised that Relax NG may be
  a better choice than schema for the types of
  extensibility being proposed.

15
Additional Issue Dial-In/Dial-Out/Refer Lists

• Currently, three separate sections in the XML
  document.
• Proposal to combine them e.g.
• lt/allowed-usersgt
• lttarget urisipalice_at_example.com
  methoddial-in /gt
• lttarget urisipbob_at_example.com
  methoddial-out /gt
• lttarget urisipcarol_at_example.com
  methodrefer /gt
• ltallowed-usersgt