Subject: [XCON] More comments on draft-ietf-xcon-framework-07.txt

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Wed, 25 Apr 2007 15:38:04 +0200

And here a bit more comments on the framework:

-The framework defines the data model as a "common conference
information". When we had the templates this concept was right but now I
think this concept is not correct. I propose to change the name to
"Conference Information Data Model" as is defined in the data model
draft.

- I think section 5.1 is a bit messy. It still have concepts about the
templates. I have re-written a bit that section to adapted it to the
data model idea: 

 "There is a core set of data in the conference system that is utilized
in any conference, independent of the specific conference media nature
(e.g., the mixing algorithms performed, the advanced floor control
applied, etc.). This core set of data contains the definitions
representing the conference object capabilities, membership, roles, call
signaling and media status relevant to different stages of the
conference life-cycle.  This core set of data is represented using the
conference information data model type defined in [17].  

New centralized conferencing specifications can extend the conference
information data model type as defined in [17] and introduce additional
data elements to be used within the conference information data model
type."

- In the 'conferencing scenario realizations' section when a user
"Alice" creates a sidebar conference. Is "Alice" included in the sidebar
conference as a user? Reading the text looks like "Alice" is included in
the sidebar but checking the figures looks like she is not part of the
sidebar conference. 

- I'm a bit confuse with the use case explain in section 9.6 'Whispering
or Private Messages'. As I understood whispering is a participant who
send a one-way message to a single participant. RFC 4597 defines
whispers or private messages as follow:
"A participant can send a one-way message (text, audio, or even some
other media) to another participant that is immediately rendered.  This
differs from a sidebar in that it is immediate and creates no long-lived
session."
The framework is defining whispering in a different way: "one
participant sends a message to multiple participants using sidebars".
For me, that definition is not connect to 'whispering or private
messages' but instead to 'sidebars'. 
As well, the use case defined in 9.6 is very confused. Why do we need to
create a sidebar and a conference ID to send a single private message to
a user? It doesn't make any sense for me. If the participant knows the
userID, he could send the whispering message straight to his friend
without create any sidebar, conferenceID or notification message.

- Section 9.9 'Observing and Coaching'. Is it necesary to create a
sidebar for observing a conference? Couldn't be the observer in the
conference a 'hidden' participant? As far as you notify the other
participant that the conference is recorded or observed by a third party
I guess it's OK, right?

- I think the intended status of the framework should be Standard track,
no informational as it is now. 
- The user identifier and the XCON identifier are defined now in the
data model. The references to those draft should be removed from the
Framework or should reference to the data model instead. 

Nits:

In some places you are using "signaling" in other "signalling".

Figure 2: Change "Common conference information type" for "Conference
Information Data Model type"
Figure 10: It's missing the clients usernames "Carol" and "Bob".
Figure 13: When Alice creates the sidebar only includes one
"confUserID". She should include at least "Bob", "Ethel" and "Carol"
user ID.
Figure 16: No sidebars are created in this uses case. So, "Active
Sidebar Conference" should be change in the picture to "Active
Conference".

Change in the text:

Cbject -> Object
Identifer-> Identifier
"And the the conference object is updated" -> "And the conference object
is updated"
"Object identifier as as shown in Figure 11" -> "Object identifier as
shown in Figure 11"
"can be handled by by supervisor adding" -> "can be handled by
supervisor adding"

Cheers,

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

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 25 Apr 2007 14:54:14 -0500

Hi Oscar,
 
Thanks for your comments. My responses are below [MB].  
 
Mary 

	-----Original Message-----
	From: Oscar Novo (JO/LMF) [mailto:[email-masked]] 
	Sent: Wednesday, April 25, 2007 8:38 AM
	To: [email-masked]
	Cc: Barnes, Mary (RICH2:AR00); [email-masked]
	Subject: More comments on draft-ietf-xcon-framework-07.txt

	[MB] Given we're post-WGLC, I'd prefer to have additional
feedback before making this change as I think the Common Conference
Information is a general enough concept and I think that change impacts
a whole lot of text and I'd be concerned that I'd break more than I
might fix with that change. [/MB]

	- I think section 5.1 is a bit messy. It still have concepts
about the templates. I have re-written a bit that section to adapted it
to the data model idea:  

	[MB]  I don't think 5.1 has template concepts at all - I removed
all of those in the -04 to -05 bunch of changes in Sept. 2006.   What
that section does have is the idea of basic conferencing with the event
package defined in RFC 4575 per the reference and then it goes on to
describe why we've done the data model draft in XCON to support the
enhanced conferencing. This gets back to the point we've discussed in
the past of ensuring that a system based on the XCON FW can also support
clients that only support RFC 4575 and not the XCON data model. [/MB]

	  "There is a core set of data in the conference system that is
utilized in any conference, independent of the specific conference media
nature (e.g., the mixing algorithms performed, the advanced floor
control applied, etc.). This core set of data contains the definitions
representing the conference object capabilities, membership, roles, call
signaling and media status relevant to different stages of the
conference life-cycle.  This core set of data is represented using the
conference information data model type defined in [17].  

	New centralized conferencing specifications can extend the
conference information data model type as defined in [17] and introduce
additional data elements to be used within the conference information
data model type."

	- In the 'conferencing scenario realizations' section when a
user "Alice" creates a sidebar conference. Is "Alice" included in the
sidebar conference as a user? Reading the text looks like "Alice" is
included in the sidebar but checking the figures looks like she is not
part of the sidebar conference.  

	[MB]  I'm not sure which figure you're referring to.  In Figures
12 and 13, I guess we could debate whether "Alice" should show up in the
Reservation, but "Alice" is shown in the "Active Sidebar Conference" in
both Figures. Is that the figures you're referring to? [/MB] 

	- I'm a bit confuse with the use case explain in section 9.6
'Whispering or Private Messages'. As I understood whispering is a
participant who send a one-way message to a single participant. RFC 4597
defines whispers or private messages as follow:

	"A participant can send a one-way message (text, audio, or even
some other media) to another participant that is immediately rendered.
This differs from a sidebar in that it is immediate and creates no
long-lived session."

	[MB] No, I don't think the framework really defines the
whispering in a different way - it does further refine that definition
in the context of the fraamework. We define "whisper" in section 4 as:

	      "A whisper involves a one-time media input to a specific
	      participant(s) within a specific conference instance,
accomplished
	      using a sidebar.  An example of a whisper would be an
announcement
	      injected only to the conference chair or to a new
participant
	      joining a conference."

	So, I think that's consistent with the definition in 4597 in
that, per the example, the sidebar is immediately removed after
delivering that onetime media.  

	As background, the definition was added in the -05, with other
text added to the document on whisper added in the -03 based on WG
discussions. I'd have to dig to find those threads, but am reluctant to
re-open past discussions without additional input from others in the WG.
[/MB]

	As well, the use case defined in 9.6 is very confused. Why do we
need to create a sidebar and a conference ID to send a single private
message to a user? It doesn't make any sense for me. If the participant
knows the userID, he could send the whispering message straight to his
friend without create any sidebar, conferenceID or notification message.

	[MB] This use case was added in the -05 version based on input
from a WG member and is consistent with the WG consensus on the
definition of whisper (which is based on a sidebar) and as I'm recalling
we did have this long, long debate. [/MB]

	 - Section 9.9 'Observing and Coaching'. Is it necesary to
create a sidebar for observing a conference? Couldn't be the observer in
the conference a 'hidden' participant? As far as you notify the other
participant that the conference is recorded or observed by a third party
I guess it's OK, right? 

	[MB] And, that's exactly what the text says - you can accomplish
the observing functionality by just having the supervisor as a hidden
participant, which is what the first two paragraphs of that section
discuss. It then describes that to take that functionality one step
further to handle the coaching:

	  " Taking the supervisor capability one step further introduces
a
	   scenario whereby the agent can hear the supervisor, as well
as the
	   customer.  The customer can still only hear the agent.  This
scenario
	   would involve the creation of a sidebar involving the agent
and the
	   supervisor. "

	[/MB] 

	- I think the intended status of the framework should be
Standard track, no informational as it is now.  

	[MB] Agreed, per previous email discussions - I'll make that
change with other nits and add that categorization to the header.  [/MB]

	- The user identifier and the XCON identifier are defined now in
the data model. The references to those draft should be removed from the
Framework or should reference to the data model instead. 

	[MB] Agreed per discussions at IETF-68.

	Nits:  

	[MB] Thanks - I'll take care of these on the next update.  

	Figure 2: Change "Common conference information type" for
"Conference Information Data Model type" 
	Figure 10: It's missing the clients usernames "Carol" and "Bob".

	Figure 16: No sidebars are created in this uses case. So,
"Active Sidebar Conference" should be change in the picture to "Active
Conference".

	Change in the text: 

	Cbject -> Object 
	Identifer-> Identifier 
	"And the the conference object is updated" -> "And the
conference object is updated" 
	"Object identifier as as shown in Figure 11" -> "Object
identifier as shown in Figure 11" 
	"can be handled by by supervisor adding" -> "can be handled by
supervisor adding" 

	Cheers, 

	Oscar Novo

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Mon, 30 Apr 2007 09:56:40 +0200

Hi Mary, 
 
I have just a coupled of comments.
 
- I still think the replacement of the "common conference information"
for "conference information data model" is important. Now, this concept
is only defined in the framework and it can be very confusing for the
readers. I don't think the substitution of this term will impact the
whole text. In the framework you have this term only in 20 places,
mainly in the 'terminology' and the 'centralized conferencing data
model' section.
 
- Regarding section 5.1 there is some text not clear and very confuse,
for instance: 
"The data model defined in [17] would be the basis for conferencing
systems supporting enhanced conferencing features.The additional
information defined in [17] provides the details of the specific media
mixing details, the associated client roles and the available floor
controls". 
The data model doesn't define any additional information. That was
defined in the template document. That's why I said that section still
have some concepts about the templates.
 
Regards,
 
Oscar

________________________________

From: Mary Barnes [mailto:[email-masked]] 
Sent: 25. huhtikuuta 2007 22:54
To: Oscar Novo (JO/LMF); [email-masked]
Cc: [email-masked]
Subject: RE: More comments on draft-ietf-xcon-framework-07.txt

Hi Oscar,

Mary 

	-----Original Message-----
	From: Oscar Novo (JO/LMF) [mailto:[email-masked]] 
	Sent: Wednesday, April 25, 2007 8:38 AM
	To: [email-masked]
	Cc: Barnes, Mary (RICH2:AR00); [email-masked]
	Subject: More comments on draft-ietf-xcon-framework-07.txt

	[/MB] 

	Nits:  

	Change in the text: 

	Cbject -> Object 
	Identifer-> Identifier 

	Cheers, 

	Oscar Novo

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 30 Apr 2007 06:36:49 -0500

Hi Oscar,
 
Responses embedded below [MB].
 
Thanks,
Mary 

	-----Original Message-----
	From: Oscar Novo (JO/LMF) [mailto:[email-masked]] 
	Sent: Monday, April 30, 2007 2:57 AM
	To: Barnes, Mary (RICH2:AR00); [email-masked]
	Cc: [email-masked]
	Subject: RE: More comments on draft-ietf-xcon-framework-07.txt

	Hi Mary, 

	- I still think the replacement of the "common conference
information" for "conference information data model" is important. Now,
this concept is only defined in the framework and it can be very
confusing for the readers. I don't think the substitution of this term
will impact the whole text. In the framework you have this term only in
20 places, mainly in the 'terminology' and the 'centralized conferencing
data model' section. 
	[MB] I do understand how the term "common" has lost its original
context since we no longer have the templates, thus there's only one set
of information. But, a global replacement won't work quite right, at
least in terms of the basic definition, where the "common conference
information" is defined as: 
	   " The common
	      conference information is the data type (i.e., the XML
schema) for
	      a conference object".  
	How about we just drop the phrase "common" and refer to it as
"Conference Information"?
	[/MB]
	 
	- Regarding section 5.1 there is some text not clear and very
confuse, for instance: 
	"The data model defined in [17] would be the basis for
conferencing systems supporting enhanced conferencing features.The
additional information defined in [17] provides the details of the
specific media mixing details, the associated client roles and the
available floor controls". 
	The data model doesn't define any additional information. That
was defined in the template document. That's why I said that section
still have some concepts about the templates. 
	[MB] Okay, now I see your specific concern.  Would it be clearer
and less confusing if we just drop "additional" from that sentence?
[/MB] 
	 
	Regards,
	 
	Oscar

	Hi Oscar,

	Mary 

		-----Original Message-----
		From: Oscar Novo (JO/LMF)
[mailto:[email-masked]] 
		Sent: Wednesday, April 25, 2007 8:38 AM
		To: [email-masked]
		Cc: Barnes, Mary (RICH2:AR00);
[email-masked]
		Subject: More comments on
draft-ietf-xcon-framework-07.txt

		-The framework defines the data model as a "common
conference information". When we had the templates this concept was
right but now I think this concept is not correct. I propose to change
the name to "Conference Information Data Model" as is defined in the
data model draft. 

		[MB] Given we're post-WGLC, I'd prefer to have
additional feedback before making this change as I think the Common
Conference Information is a general enough concept and I think that
change impacts a whole lot of text and I'd be concerned that I'd break
more than I might fix with that change. [/MB]

		- I think section 5.1 is a bit messy. It still have
concepts about the templates. I have re-written a bit that section to
adapted it to the data model idea:  

		[MB]  I don't think 5.1 has template concepts at all - I
removed all of those in the -04 to -05 bunch of changes in Sept. 2006.
What that section does have is the idea of basic conferencing with the
event package defined in RFC 4575 per the reference and then it goes on
to describe why we've done the data model draft in XCON to support the
enhanced conferencing. This gets back to the point we've discussed in
the past of ensuring that a system based on the XCON FW can also support
clients that only support RFC 4575 and not the XCON data model. [/MB]

		  "There is a core set of data in the conference system
that is utilized in any conference, independent of the specific
conference media nature (e.g., the mixing algorithms performed, the
advanced floor control applied, etc.). This core set of data contains
the definitions representing the conference object capabilities,
membership, roles, call signaling and media status relevant to different
stages of the conference life-cycle.  This core set of data is
represented using the conference information data model type defined in
[17].  

		New centralized conferencing specifications can extend
the conference information data model type as defined in [17] and
introduce additional data elements to be used within the conference
information data model type."

		- In the 'conferencing scenario realizations' section
when a user "Alice" creates a sidebar conference. Is "Alice" included in
the sidebar conference as a user? Reading the text looks like "Alice" is
included in the sidebar but checking the figures looks like she is not
part of the sidebar conference.  

		[MB]  I'm not sure which figure you're referring to.  In
Figures 12 and 13, I guess we could debate whether "Alice" should show
up in the Reservation, but "Alice" is shown in the "Active Sidebar
Conference" in both Figures. Is that the figures you're referring to?
[/MB] 

		- I'm a bit confuse with the use case explain in section
9.6 'Whispering or Private Messages'. As I understood whispering is a
participant who send a one-way message to a single participant. RFC 4597
defines whispers or private messages as follow:

		"A participant can send a one-way message (text, audio,
or even some other media) to another participant that is immediately
rendered.  This differs from a sidebar in that it is immediate and
creates no long-lived session."

		The framework is defining whispering in a different way:
"one participant sends a message to multiple participants using
sidebars". For me, that definition is not connect to 'whispering or
private messages' but instead to 'sidebars'.  

		      "A whisper involves a one-time media input to a
specific
		      participant(s) within a specific conference
instance, accomplished
		      using a sidebar.  An example of a whisper would be
an announcement
		      injected only to the conference chair or to a new
participant
		      joining a conference."

		So, I think that's consistent with the definition in
4597 in that, per the example, the sidebar is immediately removed after
delivering that onetime media.  

		As background, the definition was added in the -05, with
other text added to the document on whisper added in the -03 based on WG
discussions. I'd have to dig to find those threads, but am reluctant to
re-open past discussions without additional input from others in the WG.
[/MB]

		As well, the use case defined in 9.6 is very confused.
Why do we need to create a sidebar and a conference ID to send a single
private message to a user? It doesn't make any sense for me. If the
participant knows the userID, he could send the whispering message
straight to his friend without create any sidebar, conferenceID or
notification message. 

		[MB] This use case was added in the -05 version based on
input from a WG member and is consistent with the WG consensus on the
definition of whisper (which is based on a sidebar) and as I'm recalling
we did have this long, long debate. [/MB]

		 - Section 9.9 'Observing and Coaching'. Is it necesary
to create a sidebar for observing a conference? Couldn't be the observer
in the conference a 'hidden' participant? As far as you notify the other
participant that the conference is recorded or observed by a third party
I guess it's OK, right? 

		[MB] And, that's exactly what the text says - you can
accomplish the observing functionality by just having the supervisor as
a hidden participant, which is what the first two paragraphs of that
section discuss. It then describes that to take that functionality one
step further to handle the coaching:

		  " Taking the supervisor capability one step further
introduces a
		   scenario whereby the agent can hear the supervisor,
as well as the
		   customer.  The customer can still only hear the
agent.  This scenario
		   would involve the creation of a sidebar involving the
agent and the
		   supervisor. "

		[/MB] 

		[MB] Agreed, per previous email discussions - I'll make
that change with other nits and add that categorization to the header.
[/MB]

		- The user identifier and the XCON identifier are
defined now in the data model. The references to those draft should be
removed from the Framework or should reference to the data model
instead. 

		Nits:  

		[MB] Thanks - I'll take care of these on the next
update.  

		In some places you are using "signaling" in other
"signalling". 

		Figure 2: Change "Common conference information type"
for "Conference Information Data Model type" 
		Figure 10: It's missing the clients usernames "Carol"
and "Bob". 
		Figure 13: When Alice creates the sidebar only includes
one "confUserID". She should include at least "Bob", "Ethel" and "Carol"
user ID.

		Figure 16: No sidebars are created in this uses case.
So, "Active Sidebar Conference" should be change in the picture to
"Active Conference".

		Change in the text: 

		Cbject -> Object 
		Identifer-> Identifier 
		"And the the conference object is updated" -> "And the
conference object is updated" 
		"Object identifier as as shown in Figure 11" -> "Object
identifier as shown in Figure 11" 
		"can be handled by by supervisor adding" -> "can be
handled by supervisor adding" 

		Cheers, 

		Oscar Novo