Subject: RE: [XCON] DP4.3: Can a blueprint contain more than one template

From: "Mary Barnes" <[email-masked]>
Date: Wed, 28 Dec 2005 10:08:41 -0600

Per my response to your response on DP4.2, if the WG agrees that the
single template per blueprint is the way to go, then that does simplify
things. Basically, the additional text in the FW would be:
"A blueprint consists of a single template, as
the template approach allows for defining combinations of media types in
a single template [ref].  Whether a blueprint needs to support multiple
templates and the associated mechanism is FFS."

Mary

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Saturday, December 24, 2005 8:14 AM
To: Barnes, Mary [RICH2:B601:EXCH]
Cc: [email-masked]
Subject: Re: [XCON] DP4.3: Can a blueprint contain more than one
template

I have to admit that I find this far too complicated. I see no hope that

implementors will either understand or implement this in any 
interoperable fashion.

I think we can avoid this by concentrating on two inheritance models 
that depend on each other:

- A "datatype" (class, static) model that inherits variables; this seems

to be called templates, although C++ templates, which most implementors 
are familiar with, are something different yet again;

- A "data" (dynamic) model that is reflected in the inheritance of 
specific values ("audio only, with Joe as moderator"). By its nature, 
this would be derived from one template since each template will have 
different variables, possibly with the same name, so it makes no sense 
to inherit from several. As noted in my previous email, the root of this

tree would be a particular blueprint. A blueprint is then created just 
like any other conference.

I'm probably still not following the terminology, but, if I may say so, 
that's a sign that others who are not document authors will be similarly

confused.

Henning

Mary Barnes wrote:
> DP4.3  Is there more than one template associated with a given 
> blueprint (i.e. is a blueprint one copy of common conference 
> information, along with one template or can there be multiple 
> templates associated)? 
> 
> The current wording in the framework supports the multiple 
> template proposal; again, per the text in 7.3 and the basic 
> definition of Blueprint.  I couldn't initially see that we had an
issue
> with 
> the framework per se.
> 
> But, based on the discussion amongst the group of authors, it 
> became clear that a clarification in the FW would be useful, 
> although the viewpoints were fairly evenly split as to the need 
> for multiple templates (within a given blueprint).  There was general
> agreement that a blueprint may have more than one template associated
> with it, however, one viewpoint was the templates can be defined in a
> way that include all the combinations (e.g., rather than a blueprint
> having separate templates for audio, video, text, they are provided a
> single multimedia template that combines the 3). Whereas, another
> viewpoint was that we should still have it as an option as to whether
a
> client wants to choose multimedia or the audio, video and text
> separately (or some combination thereof).  It was generally agreed
that
> it's expeditious to define the combinations that seem reasonable into
a
> single template. However, the alternative viewpoint  was that the FW
(at
> least) shouldn't preclude offering multiple templates in a given
> blueprint. With this approach, the blueprint can be viewed as having
the
> superset that is allowed for the particular flavor of conference and
> then the client chooses and returns in the explicit reservation object
> what it wants to use, which is then validated by the conferencing
> system. 
> 
> A compromise was eventually proposed and agreed, with the proposal to
> add some text into the framework (before the 3rd paragraph in section
> 7.3 - right after the text proposed for resolution of DP4/4.1)
> mentioning something like:
> "A typical blueprint is anticipated to consist of a single template,
as
> the template approach allows for defining combinations of media types
in
> a single template [ref].  However, a blueprint may contain more than
one
> template depending upon the characteristics and configurations
supported
> by a specific conferencing system.  This approach allows a
conferencing
> system to provide the clients with additional flexibility in selecting
> the type of conference they desire."
> 
> 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