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

From: "Mary Barnes" <[email-masked]>
Date: Fri, 30 Dec 2005 13:44:38 -0600

I'm concerned that we may not all be on the same page.  I generally
agree with Brian's and Henning's statements.  The clarification I would
add is that the Blueprint also contains the Common Conference
Information, so it's more than just a set of initial values assigned to
an object conformant to the schema defined for the template. The
blueprint also contains the intial values and ranges for the elements
defined by the common conference information schema. 

If there's agreement that the blueprint also contains common conference
information, then we need to figure out where we need to clarify the
text in the framework document so that everyone reading the document
understands that and we also need to add text to emphasize the point you
two have made. I agree the current definition of Blueprint is slightly
fuzzy on the relationship between the template and the blueprint.
Perhaps, changing the last sentence of the definition would help. So, I
would propose a change from:
      "A system may maintain multiple blueprints, each comprised of the
      common conference information, along with any number of
templates."
to:
      "A system may maintain multiple blueprints. Each blueprint is 
      comprised of the initial values and ranges for the elements in 
      the object, conformant to the data schemas for the common 
      conference information and the specific template(s) associated 
      with the blueprint."

If you both are saying that the Blueprint does not contain common
conference information, then we need more discussion and input from
others, as well, as alot more proposed text changes for the document. 

Mary

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, December 29, 2005 7:46 AM
To: 'Henning'; Barnes, Mary [RICH2:B601:EXCH]
Cc: [email-masked]
Subject: RE: [XCON] DP4/4.1: Common Conference Information
andTemplates(in/out problem)

FWIW, my conception of Blueprint is the same as Henning's.  A template
is a
definition; there is a document that describes it, and probably
something
like a schema.  

The Blueprint is the set of initial values assigned to an object
conformant
to the schema. 

Brian  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning
Sent: Thursday, December 29, 2005 5:57 AM
To: Mary Barnes
Cc: [email-masked]
Subject: Re: [XCON] DP4/4.1: Common Conference Information
andTemplates(in/out problem)

Your note makes me worry that I still don't understand the template
concept.

I had earlier provided a brief definition of a template. Is that in 
agreement with yours?

In short: Template = class definition (data types); blueprint = initial 
values (dynamic). Obviously, a blueprint only makes sense within a 
particular template.

----- Original Message ----- 
From: "Mary Barnes" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 28, 2005 5:03 PM
Subject: RE: [XCON] DP4/4.1: Common Conference Information and 
Templates(in/out problem)

>I think the objective is as you state in that everything in the end
does
> get created from a blueprint (basic or customized).
>
> We were debating how customizable are the templates - I guess I don't
> see the impact on the inheritance model.  If there doesn't seem to be
> the need for this "by-reference" and multiple templates concept, then
> that does simplify things (but restricts future flexibility and
> applicability of the framework). I guess it might be reasonable at
this
> point to suggest that the data model and associated protocols will
only
> support the by-value and a single template model initially.  [That
seems
> to be what Brian Rosen is also arguing for in his response.]
>
> Mary
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, December 24, 2005 8:08 AM
> To: Barnes, Mary [RICH2:B601:EXCH]
> Cc: [email-masked]
> Subject: Re: [XCON] DP4/4.1: Common Conference Information and
Templates
> (in/out problem)
>
>
> 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
>
> Mary Barnes wrote:
>> 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
>
>
>
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 

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

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