Subject: RE: [XCON] Roni's Comments on draft-ietf-xcon-framework-01.txt

From: "Mary Barnes" <[email-masked]>
Date: Fri, 30 Sep 2005 12:42:49 -0500

Hi Roni,
 
Thanks for the detailed review.  Responses are embedded below [MB].  
 
Mary 

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Even, Roni
	Sent: Wednesday, August 31, 2005 8:23 AM
	To: [email-masked]
	Subject: [XCON] Comments on draft-ietf-xcon-framework-01.txt

	Hi,
	I read the document and find in good shape that will enable to
finish the open issues.
	My comments are more on editorial so I will have them as a one
list. If any of them will need to be discussed, I can create a separate
email.

	1. In the document you are using in some places call control
signaling and in others call signaling. 

	      My suggestion is to use call signaling. 

	 [MB] My preference would be to keep the word "control", but I
know that gets long, which is why we got lazy and dropped it in some
cases.  So, I will go ahead and make this change unless someone objects.

	2. In figure 1 there is call control client - suggest call
signaling client. 

	[MB] For consistency with the previous comment, I'll make this
change.   And, I'll also modify Figure 1 for consistency and change that
arrow that's labeled with protocols to be the "Call Signaling Protocol".

	3. In figure 1 suggest changing conference control client to
conference and media control client. 

	[MB] Agreed. 

	4. In section 4.1 "The basic common conference information can
be represented using the

	   conference-info-type schema as defined in" should be
"conference-info type" 

	[MB] Agreed.  

	5. In section 4.1, I suggest to add to the conference common
information also the media semantics and refer to
draft-hautakorpi-mmusic-sdp-media-content-01. 

	[MB]  I agree that this document would be a good reference to
add in general, but I'm not sure it needs to be discussed or brought
into this section of the document. I think this does highlight some
things that should naturally be included in the Common Conference
Information and thus implies some extensions to the conference-info-type
(or whatever is agreed based upon current discussions on
draft-novo-xcon-common-data-model-00.txt.   I think this brings us to
the more general issue of how much detail we want in this doc as to the
detailed schema. 

	6.  Section 5.1 discuss the conference identifier and claims
that the factory creates it. Using a factory is only one method to
create the conference URI. 

	[MB] Agreed.  I'll add a statement that within this model, the
factory is the one method, but that depending upon the implementation,
there may be other means of creating the conference URI.  We should
probably add an example of another means that is plausible such as a
pre-configured or out-of-band mechanism; does that sound reasonable? 

	7. In section 5.2 you have "each of them accessible by a Call
Control protocol" what is call control protocol 

	[MB] This should be, of course, the Call Signaling protocol. 

	8. Section 5.4 present the conference user identifier. There
should be an association between this identifier and the user element in
the event package so that the users in the conference can be identified
in the notifications. Maybe you can explain how the user identifier is
created in the example in 6.2 and explain the connection to the user
element in the event package. 

	[MB] Per Henning's comments, as well, we need to clarify this
section.  We'll post to the list separately, in response to Henning's
separate email on this point, how we'll resolve this issue.  

	9.  In section 6.4 you describe manipulation within a series
range of conferences. You describe that a new iCAL arrives which changes
in only part of the occurrence. Creating a clone defines the new
occurrences but what about the original reservation that has the
original times, how do you prevent them from being scheduled. You need
to either change the iCAL information for the original reservation or to
have just the iCAL linked, using a linked list, to the conference
identifier without cloning and let the system calculate the right time.

	[MB] I kinda see your point, but I don't necessarily think we
have a problem, as we are creating a new child object (which is not
independent of the parent).  So, rather than all the reservations in the
series pointing to the same object, some of them point to this new child
object.  So, I would think the concern would be that if a time change
were made to the whole series, the start time for the child would also
change, which I think would be the intent. Since, it is a child, the
parent is aware of its existence, thus any potential concerns with
changes to the parent (original reservation) should be resolvable by
first visiting the child to determine if those changes should apply
(depending upon policy, etc.). 

	10. Section 8.3 discuss sidebar is it possible to have a
participant in audio sidebar and see the presentation from the main
conference. Does this fall under the mechanism where the sidebar gets a
main conference media stream, suggest to mention that a sidebar may have
own media mixes and main conference media for other media streams. 

	[MB]   Agreed, that we should mention this case. Chris'
suggestion is that the audio sidebar has a separate mix with  the main
mix/presentation as a participant.

	Typos:

	 [MB] All fixed.  Thanks for catching these. 

	In section 6:  capabilites

	In section 8.1 it should be figure 10 instead of figure 11.

	In section 10: specificiations

	Roni Even

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