Subject: [XCON] DP4/4.1: Common Conference Information and Templates (in/out problem)

From: "Mary Barnes" <[email-masked]>
Date: Fri, 23 Dec 2005 18:11:08 -0600

Hi all,

There's been a group of us (XCON FW authors, current template authors
and data model authors) discussing this point and a couple of related
issues around the Common conference information, templates and
blueprints offline since the IETF meeting.  We've come to tenuous
agreement amongst ourselves on a couple of aspects of this topic and
wanted to continue and complete the discussion with the WG.  I'm
summarizing the issues and the changes proposed at this point to the
framework to accomodate current thinking.   I've labeled the related
questions/topics we've discussed for convenience as DP4.2 and DP4.3 and
I'll post those in separate threads to facilitate tracking the issues.
Feedback would be appreciated - ideally supported by alternative and/or
additional text . 

Per discussion at the IETF-64, there still seemed to be some debate
(beyond the basic data model approach discussed in the "Call for
Consensus:Data model" thread initiated by Adam) on some fundamentals of
the model defined in the framework.  Basically, this is the DP4 issue as
to whether the template is in the same object as the common conference
information (i.e. "in") or whether it is a separate object (i.e. "out").
The framework has been based on the "in" concept barring any other
conclusion by the WG, noting that the current definition of blueprint is
quite explicit about this:
     "A conference blueprint is a static conference
      object within a conferencing system, which describes a typical
      conference setting supported by the system.  A conference
      blueprint is the basis for creation of dynamic conference objects.
      A system may maintain multiple blueprints, each comprised of the
      common conference information, along with any number of
templates."

The discussion amongst the group seemed to lead to it's not being an
in/out issue as much as it is either by-value or by-reference.  It was
suggested that we just chooose by-value for now, but that wasn't deemed
practical in terms of the model put forth in the framework in terms of
lots of flexibility, with optionality of templates. We did (tenuously)
agree to support both.  The Blueprint concept really requires that we
support by-reference, and that's consistent with the current approach
whereby the client fetches any templates from the server that it doesn't
understand.  At the same time, a barebones system could initially just
support a few templates and by-value might make sense.  But, again, I
think it's too limiting for the vision represented in the framework to
be the only option supported.   

At this time, we're proposing something like the following be added
after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example"
section that introduces the blueprint concept) supporting the concept of
by-value or by-reference.  It might be useful to add more text including
some background for the context for using one or the other, as well:
 "As defined within this framework, a blueprint is comprised of the
common conference information and one or more templates.  The templates
within the blueprint can either be included by-value or by-reference
depending upon the system implementation." 

Mary.

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 24 Dec 2005 15:08:08 +0100

I'm concerned that we're adding too many related, but subtly, different 
inheritance concepts.

I'm still not quite sure I understand blueprints, but as described 
below, this seems awfully close to the concept of inheritance of 
individual instances ("tree").

Thus, I wonder if the two concepts can't be unified. Essentially, a 
"blueprint" becomes the root of the inheritance tree.

That way, we only have one dynamic (value) inheritance concept. This 
also makes it easy to create custom inheritance, such as "our weekly 
departmental meeting". It simply gets created from one of the 
system-defined 'blueprints'.

Henning