Subject: [XCON] Minutes, presentation online

From: adam at dynamicsoft.com (Adam Roach)
Date: Tue Jul 29 14:05:34 2003

[As chair]

The presentation and raw minutes from the XCON BOF are
now online. Please send any comments on the minutes to
me or Alan.

http://www.softarmor.com/xcon/meets/ietf57/

/a

From: Adam Roach <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 29 Jul 2003 14:05:23 -0500
Subject: [XCON] Minutes, presentation online
Sender: [email-masked]

[As chair]

The presentation and raw minutes from the XCON BOF are
now online. Please send any comments on the minutes to
me or Alan.

http://www.softarmor.com/xcon/meets/ietf57/

/a
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Dolan, Michael F (Mike)" <[email-masked]>
To: Dean Willis <[email-masked]>,  "Dolan, Michael F (Mike)" <[email-masked]>, "'Michael Hammer'" <[email-masked]>,  "Drage, Keith (Keith)" <[email-masked]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 17:16:48 -0500
Cc: [email-masked]
Sender: [email-masked]

Dean,

Good point, but if the mobile terminal is to make the choice, and assuming a lower priority talk burst arrives just slightly ahead of a higher priority talk burst, the mobile terminal may miss the notification of the second talk burst and continue to listen to the lower priority burst.

PTT floor control has to support (maybe not exclusively) the model seen in PAMR systems (e.g., TETRA in Europe) and in Nextel.

Ultimately, I think that floor control must support first-come-first-served as well as highest priority wins.  I don't see floor control being based on "who is loudest".  Individual PTT calls should be configurable for the policy to be followed.

Regards,
Mike

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, July 24, 2003 5:08 PM
To: 'Dolan, Michael F (Mike)'; 'Michael Hammer'; 'Drage, Keith (Keith)'
Cc: [email-masked]
Subject: RE: [XCON] Wireless Systems do not flee XML

Mike Dolan said: 
> Just one thought:
> In a wireless PTT environment, I don't have the luxury of 
> providing multiple voice streams to the mobile terminal and 
> letting it choose.  That choice has to be made in the network.

Or configure the client to choose only the one you want. 

--
Dean
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Dean Willis" <[email-masked]>
To: "'Dolan, Michael F \(Mike\)'" <[email-masked]>,  "'Michael Hammer'" <[email-masked]>, "'Drage, Keith \(Keith\)'" <[email-masked]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 17:08:17 -0500
Importance: Normal
Cc: [email-masked]
Sender: [email-masked]

Mike Dolan said: 
> Just one thought:
> In a wireless PTT environment, I don't have the luxury of 
> providing multiple voice streams to the mobile terminal and 
> letting it choose.  That choice has to be made in the network.

Or configure the client to choose only the one you want. 

--
Dean

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Dolan, Michael F (Mike)" <[email-masked]>
To: Michael Hammer <[email-masked]>,  "Drage, Keith (Keith)" <[email-masked]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 15:59:48 -0500
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

Mike,

Just one thought:
In a wireless PTT environment, I don't have the luxury of providing multiple voice streams to the mobile terminal and letting it choose.  That choice has to be made in the network.

Regards,
Mike Dolan
[email-masked]

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, July 24, 2003 12:48 PM
To: Drage, Keith (Keith)
Cc: [email-masked]; [email-masked]
Subject: RE: [XCON] Wireless Systems do not flee XML

Keith,

The definition of "floor control" will influence what is considered 
in-scope.  There were two closely-related aspects of what that meant to me:

Dynamic v. Static media policy
Human in the decision loop

I was thinking that the decision about who talks and who doesn't would be 
based on a higher level of intelligence about the content of the media than 
just which party is loudest when and who has a pre-programmed higher rank 
(peon, director, VP, or military ranks) than someone else.

If the pre-programmed variety is included, then of course the automaton as 
conference chair can make the decisions, human control is not needed, and 
PTT comes within the definition.  If such is the case, then merely the 
receipt of RTP packets with content from competing speakers may be enough 
to trigger the decision, assuming an active long-term conference.

I think I just had a higher bar for what is included in floor control.  I'm 
still reading various drafts to get a better picture of all of this.

Mike

At 11:05 AM 7/24/2003 +0100, Drage, Keith (Keith) wrote:
>The only thing approaching a service definition for push to talk is the 
>OMA definition for push to talk over cellular.
>
>While still in an evolving condition, this definitely has some 
>requirements for floor control in it.
>
>It is probably also worth remembering that IETF is defining the 
>conferencing service. I think we are all viewing push to talk as being a 
>subset of this, where the subset will not be defined by IETF.
>
>My previous comments regarding compression should be regarded as applying 
>to both any floor control protocol and the CPCP (assuming neither protocol 
>is sufficiently concise as to not need compression). As regards floor 
>control commands, I have heard various wireless people expressing the 
>advantages of keeping these to 30 to 40 bytes!!!
>
>regards
>
>Keith
>
> > -----Original Message-----
> > From: Michael Hammer [mailto:[email-masked]]
> > Sent: 17 July 2003 18:44
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [XCON] Wireless Systems do not flee XML
> >
> >
> > I think I would define push-to-talk as the absence of floor
> > control, i.e a
> > central controller of the floor.  At best, it is a mixer policy of
> > first-come, first-served, with loudest being a tie-breaker.
> >
> > Mike
> >
> >
> > At 12:14 PM 7/17/2003 +0300, [email-masked] wrote:
> > >I don't think this is only a question about encoding. The
> > way push to talk
> > >allocates the medium to me is much more a feature of the
> > mixer and/or the
> > >media than floor control. As far as I understand the ptt
> > functionality, it
> > >has a mixer that is basically a stream switch; only the
> > winning stream
> > >gets through, the talk bursts that arrive after the winner
> > are dropped to
> > >the floor.
> > >
> > >Having said that, trying to scale the push to talk type
> > control up to a
> > >full blown floor control with mediators etc, is an equally
> > bad idea to
> > >trying to scale down the full blown floor control to serve
> > the push to
> > >talk type talk burst switching.
> > >
> > >I'm not saying push to talk is out of scope of conferencing,
> > I'm just not
> > >sure it is wise to categorize it as floor control, at least until we
> > >understand the requirements better.
> > >
> > >Cheers,
> > >Aki
> > >
> > >  > -----Original Message-----
> > >  > From: ext [mailto:[email-masked]]
> > >  > Sent: 16 July, 2003 22:10
> > >  > To: [email-masked]; [email-masked]
> > >  > Cc: [email-masked]; [email-masked]
> > >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > > -----Original Message-----
> > >  > > From: ext Rohan Mahy [mailto:[email-masked]]
> > >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> > >  > > To: Adam Roach
> > >  > > Cc: [email-masked]; [email-masked]
> > >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> > >  > >
> > >  > >
> > >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> > >  > >
> > >  > > > [email-masked] [mailto:[email-masked]] writes:
> > >  > > >
> > >  > > >> Dean made a statement during the XCON BOF that the wireless
> > >  > > >> guys (to which I count myself) do not want XML as it would
> > >  > > >> use to much bandwidth. That is in fact not true - there were
> > >  > > >> requirements expressed that XML is the preferred
> > solution for
> > >  > > >> coding e.g. CPCP
> > >  > > >
> > >  > > > To be clear, Dean's comments were addressing the
> > >  > > > floor control protocol, not the policy control
> > >  > > > protocols. In most cases, floor control is
> > >  > > > significantly more dynamic and real-time than
> > >  > > > policy control. If the floor control protocol
> > >  > > > is inappropriately large, there are concerns that
> > >  > > > the user experience on wireless networks will be
> > >  > > > inadequate. For example, turnaround time from
> > >  > > > requesting an empty floor to receiving notification
> > >  > > > that it has been granted can't take too long,
> > >  > > > or users will become frustrated and potentially
> > >  > > > confused.
> > >  > > >
> > >  > > > That said, we haven't yet established whether XML
> > >  > > > is inappropriately heavy for floor control. I expect
> > >  > > > that further work on the floor control protocol will
> > >  > > > include an analysis of the issue.
> > >  > >
> > >  > > I would be quite happy with a simple TLV-encoded floor control
> > >  > > protocol.  I don't think a floor control protocol
> > needs any of the
> > >  > > features of XML, or rather, I don't see any compelling
> > >  > reason to use
> > >  > > XML to encode a floor-control protocol.
> > >  >
> > >  > But its hip to use XML :)
> > >  >
> > >  > I don't see XML any more complex than a text based protocol.
> > >  >
> > >  > /Hisham
> > >  >
> > >  > >
> > >  > > thanks,
> > >  > > -rohan
> > >  > >
> > >  > >
> > >  > > > /a
> > >  > > > _______________________________________________
> > >  > > > XCON mailing list
> > >  > > > [email-masked]
> > >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  > > _______________________________________________
> > >  > > XCON mailing list
> > >  > > [email-masked]
> > >  > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  >
> > >  > _______________________________________________
> > >  > XCON mailing list
> > >  > [email-masked]
> > >  > http://www.softarmor.com/mailman/listinfo/xcon
> > >  >
> > >
> > >_______________________________________________
> > >XCON mailing list
> > >[email-masked]
> > >http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 24 Jul 2003 13:47:38 -0400
To: "Drage, Keith (Keith)" <[email-masked]>
From: Michael Hammer <[email-masked]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

Keith,

The definition of "floor control" will influence what is considered 
in-scope.  There were two closely-related aspects of what that meant to me:

Dynamic v. Static media policy
Human in the decision loop

I was thinking that the decision about who talks and who doesn't would be 
based on a higher level of intelligence about the content of the media than 
just which party is loudest when and who has a pre-programmed higher rank 
(peon, director, VP, or military ranks) than someone else.

If the pre-programmed variety is included, then of course the automaton as 
conference chair can make the decisions, human control is not needed, and 
PTT comes within the definition.  If such is the case, then merely the 
receipt of RTP packets with content from competing speakers may be enough 
to trigger the decision, assuming an active long-term conference.

I think I just had a higher bar for what is included in floor control.  I'm 
still reading various drafts to get a better picture of all of this.

Mike

At 11:05 AM 7/24/2003 +0100, Drage, Keith (Keith) wrote:
>The only thing approaching a service definition for push to talk is the 
>OMA definition for push to talk over cellular.
>
>While still in an evolving condition, this definitely has some 
>requirements for floor control in it.
>
>It is probably also worth remembering that IETF is defining the 
>conferencing service. I think we are all viewing push to talk as being a 
>subset of this, where the subset will not be defined by IETF.
>
>My previous comments regarding compression should be regarded as applying 
>to both any floor control protocol and the CPCP (assuming neither protocol 
>is sufficiently concise as to not need compression). As regards floor 
>control commands, I have heard various wireless people expressing the 
>advantages of keeping these to 30 to 40 bytes!!!
>
>regards
>
>Keith
>
> > -----Original Message-----
> > From: Michael Hammer [mailto:[email-masked]]
> > Sent: 17 July 2003 18:44
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [XCON] Wireless Systems do not flee XML
> >
> >
> > I think I would define push-to-talk as the absence of floor
> > control, i.e a
> > central controller of the floor.  At best, it is a mixer policy of
> > first-come, first-served, with loudest being a tie-breaker.
> >
> > Mike
> >
> >
> > At 12:14 PM 7/17/2003 +0300, [email-masked] wrote:
> > >I don't think this is only a question about encoding. The
> > way push to talk
> > >allocates the medium to me is much more a feature of the
> > mixer and/or the
> > >media than floor control. As far as I understand the ptt
> > functionality, it
> > >has a mixer that is basically a stream switch; only the
> > winning stream
> > >gets through, the talk bursts that arrive after the winner
> > are dropped to
> > >the floor.
> > >
> > >Having said that, trying to scale the push to talk type
> > control up to a
> > >full blown floor control with mediators etc, is an equally
> > bad idea to
> > >trying to scale down the full blown floor control to serve
> > the push to
> > >talk type talk burst switching.
> > >
> > >I'm not saying push to talk is out of scope of conferencing,
> > I'm just not
> > >sure it is wise to categorize it as floor control, at least until we
> > >understand the requirements better.
> > >
> > >Cheers,
> > >Aki
> > >
> > >  > -----Original Message-----
> > >  > From: ext [mailto:[email-masked]]
> > >  > Sent: 16 July, 2003 22:10
> > >  > To: [email-masked]; [email-masked]
> > >  > Cc: [email-masked]; [email-masked]
> > >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > > -----Original Message-----
> > >  > > From: ext Rohan Mahy [mailto:[email-masked]]
> > >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> > >  > > To: Adam Roach
> > >  > > Cc: [email-masked]; [email-masked]
> > >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> > >  > >
> > >  > >
> > >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> > >  > >
> > >  > > > [email-masked] [mailto:[email-masked]] writes:
> > >  > > >
> > >  > > >> Dean made a statement during the XCON BOF that the wireless
> > >  > > >> guys (to which I count myself) do not want XML as it would
> > >  > > >> use to much bandwidth. That is in fact not true - there were
> > >  > > >> requirements expressed that XML is the preferred
> > solution for
> > >  > > >> coding e.g. CPCP
> > >  > > >
> > >  > > > To be clear, Dean's comments were addressing the
> > >  > > > floor control protocol, not the policy control
> > >  > > > protocols. In most cases, floor control is
> > >  > > > significantly more dynamic and real-time than
> > >  > > > policy control. If the floor control protocol
> > >  > > > is inappropriately large, there are concerns that
> > >  > > > the user experience on wireless networks will be
> > >  > > > inadequate. For example, turnaround time from
> > >  > > > requesting an empty floor to receiving notification
> > >  > > > that it has been granted can't take too long,
> > >  > > > or users will become frustrated and potentially
> > >  > > > confused.
> > >  > > >
> > >  > > > That said, we haven't yet established whether XML
> > >  > > > is inappropriately heavy for floor control. I expect
> > >  > > > that further work on the floor control protocol will
> > >  > > > include an analysis of the issue.
> > >  > >
> > >  > > I would be quite happy with a simple TLV-encoded floor control
> > >  > > protocol.  I don't think a floor control protocol
> > needs any of the
> > >  > > features of XML, or rather, I don't see any compelling
> > >  > reason to use
> > >  > > XML to encode a floor-control protocol.
> > >  >
> > >  > But its hip to use XML :)
> > >  >
> > >  > I don't see XML any more complex than a text based protocol.
> > >  >
> > >  > /Hisham
> > >  >
> > >  > >
> > >  > > thanks,
> > >  > > -rohan
> > >  > >
> > >  > >
> > >  > > > /a
> > >  > > > _______________________________________________
> > >  > > > XCON mailing list
> > >  > > > [email-masked]
> > >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  > > _______________________________________________
> > >  > > XCON mailing list
> > >  > > [email-masked]
> > >  > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  >
> > >  > _______________________________________________
> > >  > XCON mailing list
> > >  > [email-masked]
> > >  > http://www.softarmor.com/mailman/listinfo/xcon
> > >  >
> > >
> > >_______________________________________________
> > >XCON mailing list
> > >[email-masked]
> > >http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Drage, Keith (Keith)" <[email-masked]>
To: "'Michael Hammer'" <[email-masked]>,  [email-masked]
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 11:05:36 +0100
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

The only thing approaching a service definition for push to talk is the OMA definition for push to talk over cellular.

While still in an evolving condition, this definitely has some requirements for floor control in it.

It is probably also worth remembering that IETF is defining the conferencing service. I think we are all viewing push to talk as being a subset of this, where the subset will not be defined by IETF.

My previous comments regarding compression should be regarded as applying to both any floor control protocol and the CPCP (assuming neither protocol is sufficiently concise as to not need compression). As regards floor control commands, I have heard various wireless people expressing the advantages of keeping these to 30 to 40 bytes!!!

regards

Keith

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: 17 July 2003 18:44
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [XCON] Wireless Systems do not flee XML
> 
> 
> I think I would define push-to-talk as the absence of floor 
> control, i.e a 
> central controller of the floor.  At best, it is a mixer policy of 
> first-come, first-served, with loudest being a tie-breaker.
> 
> Mike
> 
> 
> At 12:14 PM 7/17/2003 +0300, [email-masked] wrote:
> >I don't think this is only a question about encoding. The 
> way push to talk 
> >allocates the medium to me is much more a feature of the 
> mixer and/or the 
> >media than floor control. As far as I understand the ptt 
> functionality, it 
> >has a mixer that is basically a stream switch; only the 
> winning stream 
> >gets through, the talk bursts that arrive after the winner 
> are dropped to 
> >the floor.
> >
> >Having said that, trying to scale the push to talk type 
> control up to a 
> >full blown floor control with mediators etc, is an equally 
> bad idea to 
> >trying to scale down the full blown floor control to serve 
> the push to 
> >talk type talk burst switching.
> >
> >I'm not saying push to talk is out of scope of conferencing, 
> I'm just not 
> >sure it is wise to categorize it as floor control, at least until we 
> >understand the requirements better.
> >
> >Cheers,
> >Aki
> >
> >  > -----Original Message-----
> >  > From: ext [mailto:[email-masked]]
> >  > Sent: 16 July, 2003 22:10
> >  > To: [email-masked]; [email-masked]
> >  > Cc: [email-masked]; [email-masked]
> >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> >  >
> >  >
> >  >
> >  >
> >  > > -----Original Message-----
> >  > > From: ext Rohan Mahy [mailto:[email-masked]]
> >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> >  > > To: Adam Roach
> >  > > Cc: [email-masked]; [email-masked]
> >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> >  > >
> >  > >
> >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> >  > >
> >  > > > [email-masked] [mailto:[email-masked]] writes:
> >  > > >
> >  > > >> Dean made a statement during the XCON BOF that the wireless
> >  > > >> guys (to which I count myself) do not want XML as it would
> >  > > >> use to much bandwidth. That is in fact not true - there were
> >  > > >> requirements expressed that XML is the preferred 
> solution for
> >  > > >> coding e.g. CPCP
> >  > > >
> >  > > > To be clear, Dean's comments were addressing the
> >  > > > floor control protocol, not the policy control
> >  > > > protocols. In most cases, floor control is
> >  > > > significantly more dynamic and real-time than
> >  > > > policy control. If the floor control protocol
> >  > > > is inappropriately large, there are concerns that
> >  > > > the user experience on wireless networks will be
> >  > > > inadequate. For example, turnaround time from
> >  > > > requesting an empty floor to receiving notification
> >  > > > that it has been granted can't take too long,
> >  > > > or users will become frustrated and potentially
> >  > > > confused.
> >  > > >
> >  > > > That said, we haven't yet established whether XML
> >  > > > is inappropriately heavy for floor control. I expect
> >  > > > that further work on the floor control protocol will
> >  > > > include an analysis of the issue.
> >  > >
> >  > > I would be quite happy with a simple TLV-encoded floor control
> >  > > protocol.  I don't think a floor control protocol 
> needs any of the
> >  > > features of XML, or rather, I don't see any compelling
> >  > reason to use
> >  > > XML to encode a floor-control protocol.
> >  >
> >  > But its hip to use XML :)
> >  >
> >  > I don't see XML any more complex than a text based protocol.
> >  >
> >  > /Hisham
> >  >
> >  > >
> >  > > thanks,
> >  > > -rohan
> >  > >
> >  > >
> >  > > > /a
> >  > > > _______________________________________________
> >  > > > XCON mailing list
> >  > > > [email-masked]
> >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  > > _______________________________________________
> >  > > XCON mailing list
> >  > > [email-masked]
> >  > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  >
> >  > _______________________________________________
> >  > XCON mailing list
> >  > [email-masked]
> >  > http://www.softarmor.com/mailman/listinfo/xcon
> >  >
> >
> >_______________________________________________
> >XCON mailing list
> >[email-masked]
> >http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Adam Roach <[email-masked]>
To: "'Kozdon, Peter'" <[email-masked]>,  [email-masked]
Subject: RE: [XCON] Charter
Date: Tue, 22 Jul 2003 12:54:21 -0500
Sender: [email-masked]

The issue is primarily one of keeping a well-defined
scope. The more we add, the less likely we are to
produce solid protocols in a reasonable time frame.

The linkage between the protocols that are listed
in the proposed charter is very tight. Related
applications, such as voting, lack this tight
linkage. Consequently, they can be added to systems
based on the proposed working group items by other
working groups or standards bodies without requiring
support from XCON.

/a

> -----Original Message-----
> From: Kozdon, Peter [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 16:51
> To: [email-masked]
> Subject: [XCON] Charter
> 
> 
>  Can someone please help me understand why Voting is excluded 
> from the scope
> of XCON. 
> 
>  I can understand why the actual vote counting, aggregation, 
> etc.. should be
> left to the implementation, however, the capability to make a 
> vote should be
> provided. This capability should be included in Conference 
> Control in the
> same manner as "raise hand" to get attention, slow down 
> instruction to the
> presenter, and similar actions.
> 
> 
> Thanks
> 
> Peter Kozdon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Adam Roach <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 22 Jul 2003 12:30:25 -0500
Subject: [XCON] Reminder: IPR
Sender: [email-masked]

[As chair]

I just wanted to send out a reminder that anyone aware of any
IPR associated with the proposed working group items should
bring such IPR to Alan's or my attention.

Thanks.

/a
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Adam Roach <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "'Bob Hughes'" <[email-masked]>, [email-masked]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Tue, 22 Jul 2003 12:24:33 -0500
Sender: [email-masked]

It would be perfectly reasonable to colocate a
focus with a normal user agent.

/a

> -----Original Message-----
> From: Victor A Paulsamy [mailto:[email-masked]]
> Sent: Thursday, July 17, 2003 13:20
> To: 'Bob Hughes'; [email-masked]
> Subject: RE: [XCON] Conference Controllers and Mixers
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Bob Hughes
>  
> >Please consider also:  If the UA has conferencing capability 
> (for, say,
> >between 3-6 participants) and the user still accesses the 
> conference server
> >(something that certainly happens in real life as not many people can
> >handle or be bothered with the key strokes needed to set up 
> conferences on
> >a phone), shouldn't the focus have the ability to establish 
> the conference
> >on the UA itself (for small conferences and assuming the 
> conference server
> >has some awareness of the UA's mixing capability)?  
> 
> [Victor A Paulsamy] Full-mesh conferencing is the best bet!
>  
> --victor
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Orit Levin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 22 Jul 2003 12:38:52 -0400
Subject: [XCON] Floor Control: local m-line as a resource.
Sender: [email-masked]

Floor is a group of shared resources.

As such, intuitively I understand that a floor can be, for example, all the
video resources in a conference: video streams, video mixers, video
switchers, etc.

Or a floor can be a specific audio mixer in a conference responsible for
mixing n specific user voice streams (out of total m users).

I don't understand how a media stream defined by an SDP m-line and flowing
between the user and the focus/mixer is a shared resource in a conference?
(Moreover, in most cases, an m-line defines a bidirectional stream. Media
streams in different directions have very different impact on possible
floors.)

In the bottom line, it seems to me that the shared resources (that would
make up a floor) are the conference resources (such as mixers, a shared
cursor) or a remote resources (such as a stream between a remote user and a
mixer or even a remote camera accessible by many participants) - not the
user's own media streams that are visible through its own SDP.

Thoughts?
Orit.

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Orit Levin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 22 Jul 2003 12:12:01 -0400
Subject: [XCON] Floor Control: Its usage.
Sender: [email-masked]

I admit that the Floor Control piece is less intuitive to me that the other
XCON components. I don't know whether I am alone, but I think it can be
helpful to show the usage cases of the protocol in the Floor Control drafts.

In draft-koskelainen-xcon-floor-control-req-00 I suggest expanding the
introduction section (or introducing a new "high level requirements"
section) by showing more floor control applications (i.e. conference
modes/types) that are going to be the customers of the Floor Control
Protocol.

In draft-wu-sipping-floor-control-04.txt I suggest showing what it takes to
implement a simplest audio conference with lecture mode and
questions/answers using the primitives defined in the draft. (Of course,
more examples are welcome.)

Thanks,
Orit.

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Orit Levin <[email-masked]>
To: [email-masked]
Date: Tue, 22 Jul 2003 11:17:37 -0400
Subject: [XCON] Floor Control: Charter.
Sender: [email-masked]

I am afraid I share some of the concerns expressed by Avshalom.

The reason for including the basic Floor Control Protocol as a part of XCON
is to be able to use it as the tool for building various applications when
"lecture with questions/answers" and "voting" being some of them.

Therefore I suggest including the motivation as a part of the Charter:

"The basic Floor Control Protocol will provide the tools for building
conferencing applications such as lecture with questions/answers and voting.
Standardization of the Floor Control applications is out of scope of XCON"

and removing the stand-alone "out-of-scope Voting" statement because it is
one of the many examples only.

Orit.

> -----Original Message-----
> From: Avshalom Houri [mailto:[email-masked]]
> Sent: Thursday, July 17, 2003 5:12 AM
> To: Jonathan Rosenberg
> Cc: Rosen, Brian; [email-masked]
> Subject: Re: [XCON] Charter
> 
> Voting is only an example of some type of floor control given to all
> participants for a certain period of time. If people feel that it can be
> easily added on I would agree with Brian, Jonathan & Henning. We really
> need to get this going.
> 
> Avshalom
> 
> 
> 
> 
> Jonathan Rosenberg <[email-masked]>
> 17/07/2003 11:50 AM
> 
> To
> "Rosen, Brian" <[email-masked]>
> cc
> Avshalom Houri/Haifa/IBM@IBMIL, [email-masked]
> Subject
> Re: [XCON] Charter
> 
> 
> 
> 
> 
> 
> I agree with Brian.
> 
> There is already a lot of work on the proposed charter. Let us get
> that done first.
> 
> -Jonathan R.
> 
> Rosen, Brian wrote:
> 
> > While I don't necessarily oppose the inclusion of voting, I find the
> > arguments here to not be convincing.
> >
> > I think voting is a simple request/response mechanism - you send out
> > a request for vote and you get a vote in response.  There could be
> > significant security implications on voting (for example, you may need
> > non-repudiation).  However, I think the vote object itself can
> > carry all the security itself, it won't affect the media or conference
> > policy stuff at all.
> >
> > Now, I do assume that the vote recorder is architecturally part of
> > the conference policy server.  I don't want to see a protocol between
> > the cps and the vote recorder.
> >
> > For these reasons, I think voting can be considered as an add-on
> > at any time.
> >
> > Brian
> >
> >
> >>-----Original Message-----
> >>From: Avshalom Houri [mailto:[email-masked]]
> >>Sent: Thursday, July 17, 2003 4:04 AM
> >>To: [email-masked]
> >>Subject: Re: [XCON] Charter
> >>
> >>
> >>I agree that voting should be added. It is not complex as the
> >>other issues
> >>and seems to be a thing that should
> >>designed from the beginning.
> >>In other words I am not sure that it is a layer that can be
> >>added later
> >>easily. Another point for voting is that it will
> >>certainly have some requirements on the presence protocols
> >>that will be
> >>used for the controlling the conference.
> >>
> >>Avshalom
> >>
> >>
> >>
> >>
> >>"Kozdon, Peter" <[email-masked]>
> >>Sent by: [email-masked]
> >>17/07/2003 12:50 AM
> >>
> >>To
> >>[email-masked]
> >>cc
> >>
> >>Subject
> >>[XCON] Charter
> >>
> >>
> >>
> >>
> >>
> >>
> >> Can someone please help me understand why Voting is excluded
> >>from the
> >>scope
> >>of XCON.
> >>
> >> I can understand why the actual vote counting, aggregation,
> >>etc.. should
> >>be
> >>left to the implementation, however, the capability to make a
> >>vote should
> >>be
> >>provided. This capability should be included in Conference
> >>Control in the
> >>same manner as "raise hand" to get attention, slow down
> >>instruction to the
> >>presenter, and similar actions.
> >>
> >>
> >>Thanks
> >>
> >>Peter Kozdon
> >>_______________________________________________
> >>XCON mailing list
> >>[email-masked]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> >>_______________________________________________
> >>XCON mailing list
> >>[email-masked]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> >
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
> 
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Victor A Paulsamy" <[email-masked]>
To: "'Rosen, Brian'" <[email-masked]>,  "'Bob Hughes'" <[email-masked]>, [email-masked]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Mon, 21 Jul 2003 14:30:08 -0700
Organization: Tamura Corp
Importance: Normal
Reply-To: [email-masked]
Sender: [email-masked]

I did some work to ascertain if an end system is capable of mixing media
streams that constitute a specific conference. It will be published soon as
an ID.

Regards,

--victor

>-----Original Message-----
>From: Rosen, Brian [mailto:[email-masked]] 

>We would have to have a way to determine if the end devices had
>end system mix capability, and what limits there were.

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Rosen, Brian" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "'Bob Hughes'" <[email-masked]>, [email-masked]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Mon, 21 Jul 2003 16:38:24 -0400
Sender: [email-masked]

Maybe yes, maybe no, but out of scope for this group.

The problem as stated is end system mixing, with a focus,
and it's certainly in scope.

I do hope Bob realizes that when you have the "CONF" button
do this, there is no problem for the focus to smoothly
move from end system mix to central mix when the size of
the conference goes over whatever limit the phones can handle.
Every existing participant sees a re-INVITE that just happens
to change the media stream address/ports (and maybe codecs).
So, you might be in a two-way call, press "CONF", which,
because you have a two way call, contacts the conference factory
and obtains a conference URI, and then REFERs the two way to
the focus, and then REFERs an additional party to the focus, 
creating a three way, with end-system mixing.  Another press of "CONF"
would REFER another party to the focus, which could re-INVITE
everyone to the central mixer.  You can, of course, keep going.
You can also allow any phone to do the referring, and you can,
with an appropriate UI, invite an incoming call to the conference
with or without a consultation hold.

We would have to have a way to determine if the end devices had
end system mix capability, and what limits there were.

Brian

> -----Original Message-----
> From: Victor A Paulsamy [mailto:[email-masked]]
> Sent: Thursday, July 17, 2003 2:20 PM
> To: 'Bob Hughes'; [email-masked]
> Subject: RE: [XCON] Conference Controllers and Mixers
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Bob Hughes
>  
> >Please consider also:  If the UA has conferencing capability 
> (for, say,
> >between 3-6 participants) and the user still accesses the 
> conference server
> >(something that certainly happens in real life as not many people can
> >handle or be bothered with the key strokes needed to set up 
> conferences on
> >a phone), shouldn't the focus have the ability to establish 
> the conference
> >on the UA itself (for small conferences and assuming the 
> conference server
> >has some awareness of the UA's mixing capability)?  
> 
> [Victor A Paulsamy] Full-mesh conferencing is the best bet!
>  
> --victor
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Victor A Paulsamy" <[email-masked]>
To: "'Bob Hughes'" <[email-masked]>,  [email-masked]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Thu, 17 Jul 2003 11:20:04 -0700
Organization: Tamura Corp
Importance: Normal
Reply-To: [email-masked]
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bob Hughes
 
>Please consider also:  If the UA has conferencing capability (for, say,
>between 3-6 participants) and the user still accesses the conference server
>(something that certainly happens in real life as not many people can
>handle or be bothered with the key strokes needed to set up conferences on
>a phone), shouldn't the focus have the ability to establish the conference
>on the UA itself (for small conferences and assuming the conference server
>has some awareness of the UA's mixing capability)?  

[Victor A Paulsamy] Full-mesh conferencing is the best bet!
 
--victor

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 17 Jul 2003 21:09:02 +0300
From: [email-masked]
To: [email-masked],  [email-masked]
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

Hi,

It appears there are multiple flavors of "push to talk" around. Some systems have a request-grant floor type of mechanism, some only use negative acknowlegement indication, and if the below is true some wouldn't use any signaling for floor control type functionality. There are many protocols used for this, some use proprietary RTP/RTCP extensions etc. It would probably be good to standardize a single reasonable flexible mechanism to achieve this. I think it has to be simple and fast to succeed, though, so I'm not sure if this could be done as a subset of a full-blown floor control system.

Markus

> -----Original Message-----
> From: ext Michael Hammer [mailto:[email-masked]]
> Sent: 17 July, 2003 20:44
> To: Niemi Aki (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [XCON] Wireless Systems do not flee XML
> 
> 
> I think I would define push-to-talk as the absence of floor 
> control, i.e a 
> central controller of the floor.  At best, it is a mixer policy of 
> first-come, first-served, with loudest being a tie-breaker.
> 
> Mike
> 
> 
> At 12:14 PM 7/17/2003 +0300, [email-masked] wrote:
> >I don't think this is only a question about encoding. The 
> way push to talk 
> >allocates the medium to me is much more a feature of the 
> mixer and/or the 
> >media than floor control. As far as I understand the ptt 
> functionality, it 
> >has a mixer that is basically a stream switch; only the 
> winning stream 
> >gets through, the talk bursts that arrive after the winner 
> are dropped to 
> >the floor.
> >
> >Having said that, trying to scale the push to talk type 
> control up to a 
> >full blown floor control with mediators etc, is an equally 
> bad idea to 
> >trying to scale down the full blown floor control to serve 
> the push to 
> >talk type talk burst switching.
> >
> >I'm not saying push to talk is out of scope of conferencing, 
> I'm just not 
> >sure it is wise to categorize it as floor control, at least until we 
> >understand the requirements better.
> >
> >Cheers,
> >Aki
> >
> >  > -----Original Message-----
> >  > From: ext [mailto:[email-masked]]
> >  > Sent: 16 July, 2003 22:10
> >  > To: [email-masked]; [email-masked]
> >  > Cc: [email-masked]; [email-masked]
> >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> >  >
> >  >
> >  >
> >  >
> >  > > -----Original Message-----
> >  > > From: ext Rohan Mahy [mailto:[email-masked]]
> >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> >  > > To: Adam Roach
> >  > > Cc: [email-masked]; [email-masked]
> >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> >  > >
> >  > >
> >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> >  > >
> >  > > > [email-masked] [mailto:[email-masked]] writes:
> >  > > >
> >  > > >> Dean made a statement during the XCON BOF that the wireless
> >  > > >> guys (to which I count myself) do not want XML as it would
> >  > > >> use to much bandwidth. That is in fact not true - there were
> >  > > >> requirements expressed that XML is the preferred 
> solution for
> >  > > >> coding e.g. CPCP
> >  > > >
> >  > > > To be clear, Dean's comments were addressing the
> >  > > > floor control protocol, not the policy control
> >  > > > protocols. In most cases, floor control is
> >  > > > significantly more dynamic and real-time than
> >  > > > policy control. If the floor control protocol
> >  > > > is inappropriately large, there are concerns that
> >  > > > the user experience on wireless networks will be
> >  > > > inadequate. For example, turnaround time from
> >  > > > requesting an empty floor to receiving notification
> >  > > > that it has been granted can't take too long,
> >  > > > or users will become frustrated and potentially
> >  > > > confused.
> >  > > >
> >  > > > That said, we haven't yet established whether XML
> >  > > > is inappropriately heavy for floor control. I expect
> >  > > > that further work on the floor control protocol will
> >  > > > include an analysis of the issue.
> >  > >
> >  > > I would be quite happy with a simple TLV-encoded floor control
> >  > > protocol.  I don't think a floor control protocol 
> needs any of the
> >  > > features of XML, or rather, I don't see any compelling
> >  > reason to use
> >  > > XML to encode a floor-control protocol.
> >  >
> >  > But its hip to use XML :)
> >  >
> >  > I don't see XML any more complex than a text based protocol.
> >  >
> >  > /Hisham
> >  >
> >  > >
> >  > > thanks,
> >  > > -rohan
> >  > >
> >  > >
> >  > > > /a
> >  > > > _______________________________________________
> >  > > > XCON mailing list
> >  > > > [email-masked]
> >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  > > _______________________________________________
> >  > > XCON mailing list
> >  > > [email-masked]
> >  > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  >
> >  > _______________________________________________
> >  > XCON mailing list
> >  > [email-masked]
> >  > http://www.softarmor.com/mailman/listinfo/xcon
> >  >
> >
> >_______________________________________________
> >XCON mailing list
> >[email-masked]
> >http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 17 Jul 2003 13:43:52 -0400
To: [email-masked]
From: Michael Hammer <[email-masked]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Cc: [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
--=====================_15737539==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
--=====================_15737539==_.ALT
Content-Type: text/html; charset="us-ascii"
Content-transfer-encoding: 8bit

I think I would define push-to-talk as the absence of floor control, i.e a central controller of the floor.  At best, it is a mixer policy of first-come, first-served, with loudest being a tie-breaker.

Mike

At 12:14 PM 7/17/2003 +0300, [email-masked] wrote:

I don't think this is only a question about encoding. The way push to talk allocates the medium to me is much more a feature of the mixer and/or the media than floor control. As far as I understand the ptt functionality, it has a mixer that is basically a stream switch; only the winning stream gets through, the talk bursts that arrive after the winner are dropped to the floor.

Having said that, trying to scale the push to talk type control up to a full blown floor control with mediators etc, is an equally bad idea to trying to scale down the full blown floor control to serve the push to talk type talk burst switching.

I'm not saying push to talk is out of scope of conferencing, I'm just not sure it is wise to categorize it as floor control, at least until we understand the requirements better.

Cheers,
Aki

 > -----Original Message-----
 > From: ext [ mailto:[email-masked]]
 > Sent: 16 July, 2003 22:10
 > To: [email-masked]; [email-masked]
 > Cc: [email-masked]; [email-masked]
 > Subject: RE: [XCON] Wireless Systems do not flee XML
 > 
 > 
 > 
 > 
 > > -----Original Message-----
 > > From: ext Rohan Mahy [ mailto:[email-masked]]
 > > Sent: Wednesday, July 16, 2003 3:53 PM
 > > To: Adam Roach
 > > Cc: [email-masked]; [email-masked]
 > > Subject: Re: [XCON] Wireless Systems do not flee XML
 > > 
 > > 
 > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
 > > 
 > > > [email-masked] [ mailto:[email-masked]] writes:
 > > >
 > > >> Dean made a statement during the XCON BOF that the wireless
 > > >> guys (to which I count myself) do not want XML as it would
 > > >> use to much bandwidth. That is in fact not true - there were
 > > >> requirements expressed that XML is the preferred solution for
 > > >> coding e.g. CPCP
 > > >
 > > > To be clear, Dean's comments were addressing the
 > > > floor control protocol, not the policy control
 > > > protocols. In most cases, floor control is
 > > > significantly more dynamic and real-time than
 > > > policy control. If the floor control protocol
 > > > is inappropriately large, there are concerns that
 > > > the user experience on wireless networks will be
 > > > inadequate. For example, turnaround time from
 > > > requesting an empty floor to receiving notification
 > > > that it has been granted can't take too long,
 > > > or users will become frustrated and potentially
 > > > confused.
 > > >
 > > > That said, we haven't yet established whether XML
 > > > is inappropriately heavy for floor control. I expect
 > > > that further work on the floor control protocol will
 > > > include an analysis of the issue.
 > > 
 > > I would be quite happy with a simple TLV-encoded floor control 
 > > protocol.  I don't think a floor control protocol needs any of the 
 > > features of XML, or rather, I don't see any compelling 
 > reason to use 
 > > XML to encode a floor-control protocol.
 > 
 > But its hip to use XML :)
 > 
 > I don't see XML any more complex than a text based protocol.
 > 
 > /Hisham
 > 
 > > 
 > > thanks,
 > > -rohan
 > > 
 > > 
 > > > /a
 > > > _______________________________________________
 > > > XCON mailing list
 > > > [email-masked]
 > > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > > _______________________________________________
 > > XCON mailing list
 > > [email-masked]
 > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > 
 > _______________________________________________
 > XCON mailing list
 > [email-masked]
 > http://www.softarmor.com/mailman/listinfo/xcon
 > 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon 

content-class: urn:content-classes:message
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Thu, 17 Jul 2003 05:37:25 -0400
From: "Eric Burger" <[email-masked]>
To: [email-masked]
Sender: [email-masked]

The problem is, some of the media policy implementation proposals to date (subject to change), effectively dictate a H.248.1 slave relationship between the focus and mixer.  This is because the existing policies pretty much follow H.248.1 semantics.

I would offer that H.248.1 is not the best protocol for an application to interact with a focus (to interact with a mixer).  Here the application is the user agent user interface.

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Thu, July 17, 2003 3:11 AM
> To: 'Bob Hughes'; [email-masked]
> Subject: RE: [XCON] Conference Controllers and Mixers
> 
> 
> Hi,
> I think that I would like to clarify the conferencing 
> architecture. If you
> will look at the sipping conference framework draft that was 
> written by
> Jonathan Rosenberg you will see three different logical entities. The
> conference policy server, the focus and the mixers. You can 
> also look at it
> as an application server that includes the conference policy, 
> a focus which
> does call signaling with EPs or other focus and a mixer that 
> mixes the media
> according to the information from the focus. 
> The XCON is addressing the issue of how an application from a user can
> manipulate the conference policy (including media policy). It is not
> addressing the decomposition of the conference server. For 
> example you can
> say that a conferencing bridge can be one physical unit that 
> includes both
> the focus and the mixer. You can have them in a physical 
> decomposition (BTW
> there is work done by the ITU on H.248.19 which is a package for this
> decomposition). Now in you example the distributed conference 
> can be done
> either by having one focus (or MC (MGC) in Megaco terms) and 
> many mixers (or
> MPs in Megaco terms) in that case it is one conference that 
> has one focus.
> Another way is to have one application server that will  handle many
> conferencing server (MCUs) composed out of focus and mixers, this is a
> cascaded conference. The cascaded solution involves less communication
> between the entities and is more suitable, in my opinion, to 
> geographically
> distributed architecture. It is true that we do not address 
> the issue of the
> communication between the focus and the conference policy server (or
> application server) but rather about how user application can 
> define the
> policy. I assume that this connection can be based on SIP 
> (look at 3GPP AS
> to MRF interface as an example)
> Regards
> 
> Roni Even
> 
> **********************************
> Roni Even
> VP Product Planning
> Polycom Network Systems
> 
> Tel: +972-3-9251200
> Mobile: +972-55-481099
> email: [email-masked]
> *************************************
> 
> -----Original Message-----
> From: Bob Hughes [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 6:18 PM
> To: [email-masked]
> Subject: [XCON] Conference Controllers and Mixers
> 
> 
> Steve Fisher wrote the following in a note with a different 
> subject header
> and I wanted to add a couple of comments in favor of moving the
> mixer/controller protocol back in scope.
> 
> Rohan,
> 
> In your response to Eric you state the following goal for xcon:
> 
> "The goal is to allow customers to select a
> conferencing application that can work with many vendor's mixers and
> conference servers."
> 
> I'm puzzled how this goal can be achieved when the protocol 
> between the
> application server and the mixers is explicitly out of scope for xcon?
> According to the charter, the following is out of scope: 
> "Protocol used
> between the conference controller and the mixer(s)."
> 
> Steve
> 
> Please consider:  if conference participants were in 
> different geographies
> (Europe and Aisia, for example) and an enterprise wished to 
> mix in each
> geography to minimize traffic between geos, it is unrealistic 
> to think that
> the mixer in each geography will always be from the same supplier.  It
> seems that a single focus, in this case, is in control of a call with
> multiple mixers (probably from different vendors) and the question of
> protocol becomes pretty important.
> 
> Please consider also:  If the UA has conferencing capability 
> (for, say,
> between 3-6 participants) and the user still accesses the 
> conference server
> (something that certainly happens in real life as not many people can
> handle or be bothered with the key strokes needed to set up 
> conferences on
> a phone), shouldn't the focus have the ability to establish 
> the conference
> on the UA itself (for small conferences and assuming the 
> conference server
> has some awareness of the UA's mixing capability)?  A 
> definition of the
> controller/mixer protocol would be useful here, too.  This is 
> a huge thing
> for the enterprise as many conferences are small and the 
> investment in UAs
> is large.  It seems very desirable if UA based conferencing can be
> accomplished in manner indistinguishable from central mixing 
> from the end
> user's perspective.
> 
> Thanks.
> 
> 
> Program Manager, VoIP and Voice/Data Convergence
> eBusiness On Demand Transformation;  IT Enablement
> 914-514-5016:  TL 725-7242

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 17 Jul 2003 12:14:32 +0300
From: [email-masked]
To: [email-masked],  [email-masked],  [email-masked]
Cc: [email-masked],  [email-masked]

I don't think this is only a question about encoding. The way push to talk allocates the medium to me is much more a feature of the mixer and/or the media than floor control. As far as I understand the ptt functionality, it has a mixer that is basically a stream switch; only the winning stream gets through, the talk bursts that arrive after the winner are dropped to the floor.

Having said that, trying to scale the push to talk type control up to a full blown floor control with mediators etc, is an equally bad idea to trying to scale down the full blown floor control to serve the push to talk type talk burst switching.

I'm not saying push to talk is out of scope of conferencing, I'm just not sure it is wise to categorize it as floor control, at least until we understand the requirements better.

Cheers,
Aki

 > -----Original Message-----
 > From: ext [mailto:[email-masked]]
 > Sent: 16 July, 2003 22:10
 > To: [email-masked]; [email-masked]
 > Cc: [email-masked]; [email-masked]
 > Subject: RE: [XCON] Wireless Systems do not flee XML
 > 
 > 
 > 
 > 
 > > -----Original Message-----
 > > From: ext Rohan Mahy [mailto:[email-masked]]
 > > Sent: Wednesday, July 16, 2003 3:53 PM
 > > To: Adam Roach
 > > Cc: [email-masked]; [email-masked]
 > > Subject: Re: [XCON] Wireless Systems do not flee XML
 > > 
 > > 
 > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
 > > 
 > > > [email-masked] [mailto:[email-masked]] writes:
 > > >
 > > >> Dean made a statement during the XCON BOF that the wireless
 > > >> guys (to which I count myself) do not want XML as it would
 > > >> use to much bandwidth. That is in fact not true - there were
 > > >> requirements expressed that XML is the preferred solution for
 > > >> coding e.g. CPCP
 > > >
 > > > To be clear, Dean's comments were addressing the
 > > > floor control protocol, not the policy control
 > > > protocols. In most cases, floor control is
 > > > significantly more dynamic and real-time than
 > > > policy control. If the floor control protocol
 > > > is inappropriately large, there are concerns that
 > > > the user experience on wireless networks will be
 > > > inadequate. For example, turnaround time from
 > > > requesting an empty floor to receiving notification
 > > > that it has been granted can't take too long,
 > > > or users will become frustrated and potentially
 > > > confused.
 > > >
 > > > That said, we haven't yet established whether XML
 > > > is inappropriately heavy for floor control. I expect
 > > > that further work on the floor control protocol will
 > > > include an analysis of the issue.
 > > 
 > > I would be quite happy with a simple TLV-encoded floor control 
 > > protocol.  I don't think a floor control protocol needs any of the 
 > > features of XML, or rather, I don't see any compelling 
 > reason to use 
 > > XML to encode a floor-control protocol.
 > 
 > But its hip to use XML :)
 > 
 > I don't see XML any more complex than a text based protocol.
 > 
 > /Hisham
 > 
 > > 
 > > thanks,
 > > -rohan
 > > 
 > > 
 > > > /a
 > > > _______________________________________________
 > > > XCON mailing list
 > > > [email-masked]
 > > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > > _______________________________________________
 > > XCON mailing list
 > > [email-masked]
 > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > 
 > _______________________________________________
 > XCON mailing list
 > [email-masked]
 > http://www.softarmor.com/mailman/listinfo/xcon
 > 

To: Jonathan Rosenberg <[email-masked]>
Subject: Re: [XCON] Charter
From: "Avshalom Houri" <[email-masked]>
Date: Thu, 17 Jul 2003 12:11:47 +0300
Cc: "Rosen, Brian" <[email-masked]>,  [email-masked]
Sender: [email-masked]

Voting is only an example of some type of floor control given to all 
participants for a certain period of time. If people feel that it can be 
easily added on I would agree with Brian, Jonathan & Henning. We really 
need to get this going.

Avshalom

Jonathan Rosenberg <[email-masked]> 
17/07/2003 11:50 AM

To
"Rosen, Brian" <[email-masked]>
cc
Avshalom Houri/Haifa/IBM@IBMIL, [email-masked]
Subject
Re: [XCON] Charter

I agree with Brian.

There is already a lot of work on the proposed charter. Let us get 
that done first.

-Jonathan R.

Rosen, Brian wrote:

> While I don't necessarily oppose the inclusion of voting, I find the
> arguments here to not be convincing.
> 
> I think voting is a simple request/response mechanism - you send out
> a request for vote and you get a vote in response.  There could be
> significant security implications on voting (for example, you may need
> non-repudiation).  However, I think the vote object itself can
> carry all the security itself, it won't affect the media or conference
> policy stuff at all.
> 
> Now, I do assume that the vote recorder is architecturally part of
> the conference policy server.  I don't want to see a protocol between
> the cps and the vote recorder.
> 
> For these reasons, I think voting can be considered as an add-on
> at any time.
> 
> Brian
> 
> 
>>-----Original Message-----
>>From: Avshalom Houri [mailto:[email-masked]]
>>Sent: Thursday, July 17, 2003 4:04 AM
>>To: [email-masked]
>>Subject: Re: [XCON] Charter
>>
>>
>>I agree that voting should be added. It is not complex as the 
>>other issues 
>>and seems to be a thing that should
>>designed from the beginning.
>>In other words I am not sure that it is a layer that can be 
>>added later 
>>easily. Another point for voting is that it will
>>certainly have some requirements on the presence protocols 
>>that will be 
>>used for the controlling the conference.
>>
>>Avshalom
>>
>>
>>
>>
>>"Kozdon, Peter" <[email-masked]> 
>>Sent by: [email-masked]
>>17/07/2003 12:50 AM
>>
>>To
>>[email-masked]
>>cc
>>
>>Subject
>>[XCON] Charter
>>
>>
>>
>>
>>
>>
>> Can someone please help me understand why Voting is excluded 
>>from the 
>>scope
>>of XCON. 
>>
>> I can understand why the actual vote counting, aggregation, 
>>etc.. should 
>>be
>>left to the implementation, however, the capability to make a 
>>vote should 
>>be
>>provided. This capability should be included in Conference 
>>Control in the
>>same manner as "raise hand" to get attention, slow down 
>>instruction to the
>>presenter, and similar actions.
>>
>>
>>Thanks
>>
>>Peter Kozdon
>>_______________________________________________
>>XCON mailing list
>>[email-masked]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
>>_______________________________________________
>>XCON mailing list
>>[email-masked]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 17 Jul 2003 05:03:41 -0400
From: Henning Schulzrinne <[email-masked]>
Organization: Columbia University
To: "Rosen, Brian" <[email-masked]>
Subject: Re: [XCON] Charter
Cc: [email-masked]
Sender: [email-masked]

To amplify: voting can be used and is used in many circumstances that 
have nothing to do with conferences (such as Yahoo or Slashdot 
polls...), so it better be separable. Therefore, I see no need to 
include this in the XCON scope.

Rosen, Brian wrote:

> While I don't necessarily oppose the inclusion of voting, I find the
> arguments here to not be convincing.
> 
> I think voting is a simple request/response mechanism - you send out
> a request for vote and you get a vote in response.  There could be
> significant security implications on voting (for example, you may need
> non-repudiation).  However, I think the vote object itself can
> carry all the security itself, it won't affect the media or conference
> policy stuff at all.
> 
> Now, I do assume that the vote recorder is architecturally part of
> the conference policy server.  I don't want to see a protocol between
> the cps and the vote recorder.
> 
> For these reasons, I think voting can be considered as an add-on
> at any time.
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 17 Jul 2003 04:50:28 -0400
From: Jonathan Rosenberg <[email-masked]>
Organization: dynamicsoft
To: "Rosen, Brian" <[email-masked]>
Subject: Re: [XCON] Charter
Cc: [email-masked]
Sender: [email-masked]

I agree with Brian.

There is already a lot of work on the proposed charter. Let us get 
that done first.

-Jonathan R.

Rosen, Brian wrote:

> While I don't necessarily oppose the inclusion of voting, I find the
> arguments here to not be convincing.
> 
> I think voting is a simple request/response mechanism - you send out
> a request for vote and you get a vote in response.  There could be
> significant security implications on voting (for example, you may need
> non-repudiation).  However, I think the vote object itself can
> carry all the security itself, it won't affect the media or conference
> policy stuff at all.
> 
> Now, I do assume that the vote recorder is architecturally part of
> the conference policy server.  I don't want to see a protocol between
> the cps and the vote recorder.
> 
> For these reasons, I think voting can be considered as an add-on
> at any time.
> 
> Brian
> 
> 
>>-----Original Message-----
>>From: Avshalom Houri [mailto:[email-masked]]
>>Sent: Thursday, July 17, 2003 4:04 AM
>>To: [email-masked]
>>Subject: Re: [XCON] Charter
>>
>>
>>I agree that voting should be added. It is not complex as the 
>>other issues 
>>and seems to be a thing that should
>>designed from the beginning.
>>In other words I am not sure that it is a layer that can be 
>>added later 
>>easily. Another point for voting is that it will
>>certainly have some requirements on the presence protocols 
>>that will be 
>>used for the controlling the conference.
>>
>>Avshalom
>>
>>
>>
>>
>>"Kozdon, Peter" <[email-masked]> 
>>Sent by: [email-masked]
>>17/07/2003 12:50 AM
>>
>>To
>>[email-masked]
>>cc
>>
>>Subject
>>[XCON] Charter
>>
>>
>>
>>
>>
>>
>> Can someone please help me understand why Voting is excluded 
>>from the 
>>scope
>>of XCON. 
>>
>> I can understand why the actual vote counting, aggregation, 
>>etc.. should 
>>be
>>left to the implementation, however, the capability to make a 
>>vote should 
>>be
>>provided. This capability should be included in Conference 
>>Control in the
>>same manner as "raise hand" to get attention, slow down 
>>instruction to the
>>presenter, and similar actions.
>>
>>
>>Thanks
>>
>>Peter Kozdon
>>_______________________________________________
>>XCON mailing list
>>[email-masked]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
>>_______________________________________________
>>XCON mailing list
>>[email-masked]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Rosen, Brian" <[email-masked]>
To: "'Avshalom Houri'" <[email-masked]>,  [email-masked]
Subject: RE: [XCON] Charter
Date: Thu, 17 Jul 2003 04:43:54 -0400
Sender: [email-masked]

While I don't necessarily oppose the inclusion of voting, I find the
arguments here to not be convincing.

I think voting is a simple request/response mechanism - you send out
a request for vote and you get a vote in response.  There could be
significant security implications on voting (for example, you may need
non-repudiation).  However, I think the vote object itself can
carry all the security itself, it won't affect the media or conference
policy stuff at all.

Now, I do assume that the vote recorder is architecturally part of
the conference policy server.  I don't want to see a protocol between
the cps and the vote recorder.

For these reasons, I think voting can be considered as an add-on
at any time.

Brian

> -----Original Message-----
> From: Avshalom Houri [mailto:[email-masked]]
> Sent: Thursday, July 17, 2003 4:04 AM
> To: [email-masked]
> Subject: Re: [XCON] Charter
> 
> 
> I agree that voting should be added. It is not complex as the 
> other issues 
> and seems to be a thing that should
> designed from the beginning.
> In other words I am not sure that it is a layer that can be 
> added later 
> easily. Another point for voting is that it will
> certainly have some requirements on the presence protocols 
> that will be 
> used for the controlling the conference.
> 
> Avshalom
> 
> 
> 
> 
> "Kozdon, Peter" <[email-masked]> 
> Sent by: [email-masked]
> 17/07/2003 12:50 AM
> 
> To
> [email-masked]
> cc
> 
> Subject
> [XCON] Charter
> 
> 
> 
> 
> 
> 
>  Can someone please help me understand why Voting is excluded 
> from the 
> scope
> of XCON. 
> 
>  I can understand why the actual vote counting, aggregation, 
> etc.. should 
> be
> left to the implementation, however, the capability to make a 
> vote should 
> be
> provided. This capability should be included in Conference 
> Control in the
> same manner as "raise hand" to get attention, slow down 
> instruction to the
> presenter, and similar actions.
> 
> 
> Thanks
> 
> Peter Kozdon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

To: [email-masked]
Subject: Re: [XCON] Charter
From: "Avshalom Houri" <[email-masked]>
Date: Thu, 17 Jul 2003 11:04:08 +0300
Sender: [email-masked]

I agree that voting should be added. It is not complex as the other issues 
and seems to be a thing that should
designed from the beginning.
In other words I am not sure that it is a layer that can be added later 
easily. Another point for voting is that it will
certainly have some requirements on the presence protocols that will be 
used for the controlling the conference.

Avshalom

"Kozdon, Peter" <[email-masked]> 
Sent by: [email-masked]
17/07/2003 12:50 AM

To
[email-masked]
cc

Subject
[XCON] Charter

 Can someone please help me understand why Voting is excluded from the 
scope
of XCON. 

 I can understand why the actual vote counting, aggregation, etc.. should 
be
left to the implementation, however, the capability to make a vote should 
be
provided. This capability should be included in Conference Control in the
same manner as "raise hand" to get attention, slow down instruction to the
presenter, and similar actions.

Thanks

Peter Kozdon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Even, Roni" <[email-masked]>
To: "'Bob Hughes'" <[email-masked]>,  [email-masked]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Thu, 17 Jul 2003 10:10:43 +0300
Sender: [email-masked]

Hi,
I think that I would like to clarify the conferencing architecture. If you
will look at the sipping conference framework draft that was written by
Jonathan Rosenberg you will see three different logical entities. The
conference policy server, the focus and the mixers. You can also look at it
as an application server that includes the conference policy, a focus which
does call signaling with EPs or other focus and a mixer that mixes the media
according to the information from the focus. 
The XCON is addressing the issue of how an application from a user can
manipulate the conference policy (including media policy). It is not
addressing the decomposition of the conference server. For example you can
say that a conferencing bridge can be one physical unit that includes both
the focus and the mixer. You can have them in a physical decomposition (BTW
there is work done by the ITU on H.248.19 which is a package for this
decomposition). Now in you example the distributed conference can be done
either by having one focus (or MC (MGC) in Megaco terms) and many mixers (or
MPs in Megaco terms) in that case it is one conference that has one focus.
Another way is to have one application server that will  handle many
conferencing server (MCUs) composed out of focus and mixers, this is a
cascaded conference. The cascaded solution involves less communication
between the entities and is more suitable, in my opinion, to geographically
distributed architecture. It is true that we do not address the issue of the
communication between the focus and the conference policy server (or
application server) but rather about how user application can define the
policy. I assume that this connection can be based on SIP (look at 3GPP AS
to MRF interface as an example)
Regards

Roni Even

**********************************
Roni Even
VP Product Planning
Polycom Network Systems

Tel: +972-3-9251200
Mobile: +972-55-481099
email: [email-masked]
*************************************

-----Original Message-----
From: Bob Hughes [mailto:[email-masked]]
Sent: Wednesday, July 16, 2003 6:18 PM
To: [email-masked]
Subject: [XCON] Conference Controllers and Mixers

Steve Fisher wrote the following in a note with a different subject header
and I wanted to add a couple of comments in favor of moving the
mixer/controller protocol back in scope.

Rohan,

In your response to Eric you state the following goal for xcon:

"The goal is to allow customers to select a
conferencing application that can work with many vendor's mixers and
conference servers."

I'm puzzled how this goal can be achieved when the protocol between the
application server and the mixers is explicitly out of scope for xcon?
According to the charter, the following is out of scope: "Protocol used
between the conference controller and the mixer(s)."

Steve

Please consider:  if conference participants were in different geographies
(Europe and Aisia, for example) and an enterprise wished to mix in each
geography to minimize traffic between geos, it is unrealistic to think that
the mixer in each geography will always be from the same supplier.  It
seems that a single focus, in this case, is in control of a call with
multiple mixers (probably from different vendors) and the question of
protocol becomes pretty important.

Please consider also:  If the UA has conferencing capability (for, say,
between 3-6 participants) and the user still accesses the conference server
(something that certainly happens in real life as not many people can
handle or be bothered with the key strokes needed to set up conferences on
a phone), shouldn't the focus have the ability to establish the conference
on the UA itself (for small conferences and assuming the conference server
has some awareness of the UA's mixing capability)?  A definition of the
controller/mixer protocol would be useful here, too.  This is a huge thing
for the enterprise as many conferences are small and the investment in UAs
is large.  It seems very desirable if UA based conferencing can be
accomplished in manner indistinguishable from central mixing from the end
user's perspective.

Thanks.

Program Manager, VoIP and Voice/Data Convergence
eBusiness On Demand Transformation;  IT Enablement
914-514-5016:  TL 725-7242

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Kozdon, Peter" <[email-masked]>
To: [email-masked]
Subject: [XCON] Charter
Date: Wed, 16 Jul 2003 14:50:46 -0700
Sender: [email-masked]

 Can someone please help me understand why Voting is excluded from the scope
of XCON. 

 I can understand why the actual vote counting, aggregation, etc.. should be
left to the implementation, however, the capability to make a vote should be
provided. This capability should be included in Conference Control in the
same manner as "raise hand" to get attention, slow down instruction to the
presenter, and similar actions.

Thanks

Peter Kozdon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Wed, 16 Jul 2003 14:07:17 -0500
From: Alan Johnston <[email-masked]>
Subject: Re: [XCON] Comments on draft-ietf-sipping-cc-conferencing-01
To: Eric Burger <[email-masked]>,  "IETF XCON Discussion List (E-mail)" <[email-masked]>
Sender: [email-masked]

FYI, I have answered Eric's questions (and one from another XCON posting) 
on the SIPPING list as this discussion is out of scope for XCON.

However, sometimes it will be in scope to discuss some XCON-related aspects 
of the High Level SIP Conferencing Requirements and Framework documents and 
that's OK.

It will also be useful from time to time to give SIP/SDP signaling examples 
when discussing XCON protocols for motivation, background, etc.  However, 
the majority of SIP conferencing discussions should be held on the SIPPING 
list.

Thanks,
Alan Johnston
MCI

At 11:09 AM 7/14/2003 -0400, Eric Burger wrote:
>[on XCON list, even though a SIPPING draft]
>
>Section 3.4:
>I'm hesitant to say a conference aware UA SHOULD subscribe to conference 
>state.  That's really an application decision.  One might suggest it, 
>e.g., "the UA can subscribe to the conference state."  A similar sentiment 
>goes for the following paragraph.  Why would or why would not a UA want to 
>display information gleaned from SIP?  In any event, it is not a protocol 
>issue, so it doesn't really merit a MAY (or SHOULD).
>
>
>Section 4.2:
>How else, in the SIP world, would a focus bring a user agent into the 
>conference other than by INVITE?  Maybe the SHOULD here is the inclusion 
>of the ;isfocus parameter.  That said, why is it not MUST?
>
>Section 4.3:
>Having the scars of Early Media from netann, I would suggest not going 
>down the path of IVR interactions before session establishment 
>completes.  There are a lot of ugly corner cases to think of and work 
>around.  I would drop the paragraph.
>
>Section 4.6:
>Same as 4.2, but with REFER.  Is the SHOULD that REFER is preferred to a 
>new INVITE or that ;isfocus SHOULD be in the contact.  If the former, this 
>is the SIPPING work group, the only thing we can spec is SIP stuff, and 
>thus this is redundant.  If it is the latter, then is there a reason 
>including ;isfocus is not mandatory?
>
>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 22:10:17 +0300
From: [email-masked]
To: [email-masked],  [email-masked]
Cc: [email-masked],  [email-masked]

> -----Original Message-----
> From: ext Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 3:53 PM
> To: Adam Roach
> Cc: [email-masked]; [email-masked]
> Subject: Re: [XCON] Wireless Systems do not flee XML
> 
> 
> On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> 
> > [email-masked] [mailto:[email-masked]] writes:
> >
> >> Dean made a statement during the XCON BOF that the wireless
> >> guys (to which I count myself) do not want XML as it would
> >> use to much bandwidth. That is in fact not true - there were
> >> requirements expressed that XML is the preferred solution for
> >> coding e.g. CPCP
> >
> > To be clear, Dean's comments were addressing the
> > floor control protocol, not the policy control
> > protocols. In most cases, floor control is
> > significantly more dynamic and real-time than
> > policy control. If the floor control protocol
> > is inappropriately large, there are concerns that
> > the user experience on wireless networks will be
> > inadequate. For example, turnaround time from
> > requesting an empty floor to receiving notification
> > that it has been granted can't take too long,
> > or users will become frustrated and potentially
> > confused.
> >
> > That said, we haven't yet established whether XML
> > is inappropriately heavy for floor control. I expect
> > that further work on the floor control protocol will
> > include an analysis of the issue.
> 
> I would be quite happy with a simple TLV-encoded floor control 
> protocol.  I don't think a floor control protocol needs any of the 
> features of XML, or rather, I don't see any compelling reason to use 
> XML to encode a floor-control protocol.

But its hip to use XML :)

I don't see XML any more complex than a text based protocol.

/Hisham

> 
> thanks,
> -rohan
> 
> 
> > /a
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

content-class: urn:content-classes:message
Subject: RE: [XCON] RE: Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 21:45:30 +0300
From: [email-masked]
To: [email-masked],  [email-masked],  [email-masked],  [email-masked]
Sender: [email-masked]

Hi,

I agree with Markus.

Floor control protocol (at least the floor claim/grant/deny part of it) should 
not be used in time-critical applications like push to talk.

Typical floor controlled application scenarios involve floor chair (human being)
who grants or denies the floor claim. There is also claim queue management
involved as there may several floor claims waiting for turn. 
This is not very time-critical (and often there are couple of people ahead of 
you in the floor claim queue anyway).
Floor claim request may include additional information, e.g. priority or 
topic of your comment (chair can better control the floor queue if he knows
in advance what is the topic of the comment).
XML (and SOAP) is logical solution for this, as defined in draft-wu-sipping-floor-control.

Push to talk like applications definitely should not use floor chairs or floor claim requests
as it would be too slow. Instead, they should use fixed media and floor policies 
(something like "no floor control protocol for media X, first speaker is passed through"). 
In the rare case that this did not work out (e.g. two persons starts speaking at the same time) 
then there may be negative notification, as markus pointed out. So this kind of application might 
utilize XML/SOAP only for floor creation. Anyway, this specific example is a service 
and IETF does not specify services.

> I think it would make sense to include the support for this kind of scenario also under 
> the "floor control" work item in XCON.

We tried to support this in floor control draft (e.g. create_floor defines the floor policy 
which says whether floor claims are used) but it seems that this work must be better aligned 
with media policy work. 

--
Petri

> -----Original Message-----
> From: ext [mailto:[email-masked]]
> Sent: 16 July, 2003 18:24
> To: [email-masked]; Mayer Georg (NMP/Helsinki);
> [email-masked]
> Subject: RE: [XCON] RE: Wireless Systems do not flee XML
> 
> 
> Hi,
> 
> I agree that for certain floor control operations latency is 
> clearly the most important issue in wireless networks. Push 
> to talk type of applications require some very efficient 
> mechanism to compete for the "floor", in which case some 
> other enconding than XML would seem reasonable.
> 
> Actually, for some applications it would be enough just to do 
> the contention with the media (i.e. the RTP packets carrying 
> the talkburst), and then just to learn if you did NOT get the 
> floor through some simple protocol message (in which case the 
> person talking would get some negative indication). In other 
> words this means that you always don't need to first 
> explicitly reserve the floor for you before starting to send 
> the media. I believe this is how it works in most of the 
> proprietary push to talk apps.
> 
> I think it would make sense to include the support for this 
> kind of scenario also under the "floor control" work item in 
> XCON. First we would ofcourse need some more specifric 
> requirements text. 
> 
> Markus   
> 
> > -----Original Message-----
> > From: ext Dean Willis [mailto:[email-masked]]
> > Sent: 16 July, 2003 11:12
> > To: Mayer Georg (NMP/Helsinki); [email-masked]
> > Subject: [XCON] RE: Wireless Systems do not flee XML
> > 
> > 
> > Georg said:
> > 
> > > Dean made a statement during the XCON BOF that the wireless 
> > > guys (to which I count myself) do not want XML as it would 
> > > use to much bandwidth. That is in fact not true - there were 
> > > requirements expressed that XML is the preferred solution for 
> > > coding e.g. CPCP, as this would allow us XML also for XCON 
> > > purposes and we would not need to implement the next encoder 
> > > in our devices. This was actually a requirement that clearly 
> > > came out from the last 3G CN1 meeting.
> > 
> > 
> > I was specifically worried about XML for floor management in 
> > a conference.
> > 
> > Within the "other" mobile community (3GPP2 -- CDMA) everybody 
> > that I've
> > talked is of the belief that the floor control messages for 
> > PoC (push talk
> > over cellular) will need to be down in the 20-30 byte range 
> (including
> > headers after ROHC) to work optimally with CDMA2000. This 
> > allows them to
> > transmit in a single short data burst. 
> > 
> > XML for configuration and other non-real-time data seems to be ok.
> > 
> > --
> > Dean
> > 
> > 
> > 
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Wed, 16 Jul 2003 21:26:19 +0300
From: [email-masked]
To: [email-masked],  [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Hi,

I think we get a better idea on compression needs, once we get more mature message flows for the most common XCAP operations. This obviously depends on how the schemas and partial updates will finally look like. My early guess is that gzip for the XML payload would be sufficient at least for presence-related operations. Conference and media policy control probably have stricter latency reqs from usability point of view. In extreme cases reuse of SigComp might be considered. (So that nobody needs to point that out, I note that obviously there is no decision that XCAP or even XML or HTTP would be used for conference control, although this would be nice.) As said, for certain type of floor control cases, binary encoding to start with would be preferred.

Markus

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 15 July, 2003 23:21
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [XCON] 3GPP Requirements on CPCP
> 
> 
> One of the differences between SIP and HTTP is that HTTP 
> tends to have 
> much fewer mandatory headers. As such, I would expect that when used 
> in XCAP, there would be few headers, probably just Content-Type. In 
> that case, one option is to perform compression on just the 
> body. This 
> is reasonably efficient when the body represents a much larger 
> percentage of the overall byte count, compared to headers. For that, 
> you can using the existing HTTP Content-Encoding facilities, using 
> something like gzip. This would avoid the need for any additional 
> standardization work to compress this stuff.
> 
> -Jonathan R.
> 
> Drage, Keith (Keith) wrote:
> 
> > Independently of any discussion of which protocol is 
> chosen, we do need to consider the implications on the radio 
> interface of any protocol chosen. There would seem to be a 
> number of decisions that it would be appropriate to make in 
> this regard.
> > 
> > 1)	Do we select/design a lightweight protocol, making 
> efficient use of individual bits, or select/design a rather 
> heavier weight text-based protocol and then compress it. 
> Previous decisions in the SIP area would suggest we go for 
> the latter, but there ought to be some explicit decision in 
> this respect.
> > 
> > 2)	Assuming that we opt for a protocol that requires 
> compression, do we specify a standard compression algorithm, 
> or do we select SIGCOMP (RFC3320) which allows downloading of 
> the compression algorithm from sender to receiver. Again SIP 
> has selected SIGCOMP as the appropriate protocol to perform 
> compression and that could well be followed here.
> > 
> > 3)	Assuming SIGCOMP is chosen, is there a need to 
> specificy a dictionary.
> > 
> > 4)	If a dictionary is specified, then is that dictionary 
> one and the same dictionary as that specified for SIP (see 
> RFC3485) is there a need for a different dictionary. (Note 
> that if a second dictionary is specified, then this 
> presumably increases the information that would need to be 
> stored in a mobile handset, and this is a finite resource.)
> > 
> > 5)	If compression is supported, is there a need for an 
> indication in the protocol that the entity is willing to use 
> compression, as specified already for SIP (see RFC3486).
> > 
> > Finally, it would need to be clarified in the XCON group as 
> to which of these decisions should be made by XCON, and which 
> it should let other groups do (e.g. for SIP the choice and 
> design of the SIGCOMP was performed by the ROHC group).
> > 
> > regards
> > 
> > Keith
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]]
> >>Sent: 10 July 2003 12:59
> >>To: [email-masked]
> >>Subject: [XCON] 3GPP Requirements on CPCP
> >>
> >>
> >>Hello,
> >>
> >>initially I planned to have a short presentation at the 
> >>Vienna meeting on 3GPP requirements on CPCP, but 
> >>unfortunately it seems that there is no time slot neither in 
> >>SIPPING nor XCON which allows going into technical 
> >>discussions during this meeting. So I decided to make my 
> >>comments on the mailing list.
> >>
> >>As you know in 3GPP we are planning to adopt the SIP 
> >>conferencing solution for the IMS (IP Multimedia Subsystem). 
> >>During the last (CN1 WG) meeting we had some discussions on 
> >>CPCP and decided that we will also adopt this solution, 
> >>although some delegates had some concerns. I therefore got 
> >>the task to collect requirements on CPCP, what I did.
> >>
> >>As always, the resources in wireless devices are a sacred 
> >>thing and therefore the main concern was, that CPCP will 
> >>introduce a whole new protocol and notation, that needs to be 
> >>implemented "just" for CPCP. Therefore the main issues are:
> >>
> >>1) that CPCP makes use of an notation mechanism that is 
> >>already used within the IMS / SIP protocol. We think that XML 
> >>is the way forward here. 
> >>
> >>2) that CPCP makes use of a protocol that is already used in 
> >>state-of-the-art wireless devices. As SIP is not an option 
> >>here, we very much favour HTTP, as this is implemented in 
> >>every new mobile phone model.
> >>
> >>As the 3GPP architecture sees the protocols for any sort of 
> >>application specific data manipulation over the same (Ut) 
> >>interface, we also favour the approach to harmonize the data 
> >>manipulation solutions as much as possible. I am aware that 
> >>CPCP is more than just data manipulation, nevertheless there 
> >>are very similar concepts in e.g. Presence DM and CPCP. As 
> >>the IMS will also include (SIMPLE based) Presence and 
> >>Presence Data Manipulation, we also see the need
> >>
> >>3) that CPCP and Presence Data Manipulation solution must be 
> >>aligned, in order to re-use as much functionality as possible.
> >>
> >>This is also important, as we see lots of services in the 
> >>future, which will also require Data Manipulation via the Ut 
> >>interface - we want these solutions harmonized if possible. 
> >>The XCAP proposal as currently discussed in SIMPLE seems to 
> >>be the right way forward here. 
> >>
> >>Finally there is a need that the UE gets aware of the CPCP 
> >>server. This might be outside of the scope of XCON, maybe 
> >>more related to SIPPING, but as it is related to this issue, 
> >>I would like to see it also listed:
> >>
> >>4) There must be a way for the UE to get aware of the address 
> >>of a CPCP server (or any other server which allows the UE to 
> >>perform data manipulation).
> >>
> >>If the group agrees, I would reformulate these requirements 
> >>into "requirements language", so that they can be added to 
> >>CPCP requirements draft (draft-koskelainen-xcon-cpcp-reqs-00.txt). 
> >>
> >>Thank you and best regards
> >>Georg
> >>
> >>
> >>_______________________________________________
> >>XCON mailing list
> >>[email-masked]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> > 
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] RE: Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 18:23:35 +0300
From: [email-masked]
To: [email-masked],  [email-masked],  [email-masked]
Sender: [email-masked]

Hi,

I agree that for certain floor control operations latency is clearly the most important issue in wireless networks. Push to talk type of applications require some very efficient mechanism to compete for the "floor", in which case some other enconding than XML would seem reasonable.

Actually, for some applications it would be enough just to do the contention with the media (i.e. the RTP packets carrying the talkburst), and then just to learn if you did NOT get the floor through some simple protocol message (in which case the person talking would get some negative indication). In other words this means that you always don't need to first explicitly reserve the floor for you before starting to send the media. I believe this is how it works in most of the proprietary push to talk apps.

I think it would make sense to include the support for this kind of scenario also under the "floor control" work item in XCON. First we would ofcourse need some more specifric requirements text. 

Markus   

> -----Original Message-----
> From: ext Dean Willis [mailto:[email-masked]]
> Sent: 16 July, 2003 11:12
> To: Mayer Georg (NMP/Helsinki); [email-masked]
> Subject: [XCON] RE: Wireless Systems do not flee XML
> 
> 
> Georg said:
> 
> > Dean made a statement during the XCON BOF that the wireless 
> > guys (to which I count myself) do not want XML as it would 
> > use to much bandwidth. That is in fact not true - there were 
> > requirements expressed that XML is the preferred solution for 
> > coding e.g. CPCP, as this would allow us XML also for XCON 
> > purposes and we would not need to implement the next encoder 
> > in our devices. This was actually a requirement that clearly 
> > came out from the last 3G CN1 meeting.
> 
> 
> I was specifically worried about XML for floor management in 
> a conference.
> 
> Within the "other" mobile community (3GPP2 -- CDMA) everybody 
> that I've
> talked is of the belief that the floor control messages for 
> PoC (push talk
> over cellular) will need to be down in the 20-30 byte range (including
> headers after ROHC) to work optimally with CDMA2000. This 
> allows them to
> transmit in a single short data burst. 
> 
> XML for configuration and other non-real-time data seems to be ok.
> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

To: [email-masked]
From: "Bob Hughes" <[email-masked]>
Date: Wed, 16 Jul 2003 11:18:01 -0400
Subject: [XCON] Conference Controllers and Mixers
Sender: [email-masked]

Steve Fisher wrote the following in a note with a different subject header
and I wanted to add a couple of comments in favor of moving the
mixer/controller protocol back in scope.

Rohan,

In your response to Eric you state the following goal for xcon:

"The goal is to allow customers to select a
conferencing application that can work with many vendor's mixers and
conference servers."

I'm puzzled how this goal can be achieved when the protocol between the
application server and the mixers is explicitly out of scope for xcon?
According to the charter, the following is out of scope: "Protocol used
between the conference controller and the mixer(s)."

Steve

Please consider:  if conference participants were in different geographies
(Europe and Aisia, for example) and an enterprise wished to mix in each
geography to minimize traffic between geos, it is unrealistic to think that
the mixer in each geography will always be from the same supplier.  It
seems that a single focus, in this case, is in control of a call with
multiple mixers (probably from different vendors) and the question of
protocol becomes pretty important.

Please consider also:  If the UA has conferencing capability (for, say,
between 3-6 participants) and the user still accesses the conference server
(something that certainly happens in real life as not many people can
handle or be bothered with the key strokes needed to set up conferences on
a phone), shouldn't the focus have the ability to establish the conference
on the UA itself (for small conferences and assuming the conference server
has some awareness of the UA's mixing capability)?  A definition of the
controller/mixer protocol would be useful here, too.  This is a huge thing
for the enterprise as many conferences are small and the investment in UAs
is large.  It seems very desirable if UA based conferencing can be
accomplished in manner indistinguishable from central mixing from the end
user's perspective.

Thanks.

Program Manager, VoIP and Voice/Data Convergence
eBusiness On Demand Transformation;  IT Enablement
914-514-5016:  TL 725-7242

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Wed, 16 Jul 2003 05:53:12 -0700
Subject: Re: [XCON] Wireless Systems do not flee XML
Cc: [email-masked],  [email-masked],  [email-masked]
To: Adam Roach <[email-masked]>
From: Rohan Mahy <[email-masked]>

On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:

> [email-masked] [mailto:[email-masked]] writes:
>
>> Dean made a statement during the XCON BOF that the wireless
>> guys (to which I count myself) do not want XML as it would
>> use to much bandwidth. That is in fact not true - there were
>> requirements expressed that XML is the preferred solution for
>> coding e.g. CPCP
>
> To be clear, Dean's comments were addressing the
> floor control protocol, not the policy control
> protocols. In most cases, floor control is
> significantly more dynamic and real-time than
> policy control. If the floor control protocol
> is inappropriately large, there are concerns that
> the user experience on wireless networks will be
> inadequate. For example, turnaround time from
> requesting an empty floor to receiving notification
> that it has been granted can't take too long,
> or users will become frustrated and potentially
> confused.
>
> That said, we haven't yet established whether XML
> is inappropriately heavy for floor control. I expect
> that further work on the floor control protocol will
> include an analysis of the issue.

I would be quite happy with a simple TLV-encoded floor control 
protocol.  I don't think a floor control protocol needs any of the 
features of XML, or rather, I don't see any compelling reason to use 
XML to encode a floor-control protocol.

thanks,
-rohan

> /a
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon

Date: Wed, 16 Jul 2003 04:22:48 -0400
From: Henning Schulzrinne <[email-masked]>
Organization: Columbia University
To: Adam Roach <[email-masked]>
CC: [email-masked],  [email-masked],  [email-masked],  Xiaotao Wu <[email-masked]>
Subject: Re: [XCON] Wireless Systems do not flee XML

In general, we probably need to distinguish two forms of overhead, 
namely the SOAP encapsulation XML and the 'real' XML.

Secondly, the evaluation may well be different for full-featured 
commands that create a floor, for example. These are likely to be used 
infrequently, so byte efficiency is somewhat secondary.

One solution is to have a trivial alternative that supports only the 
"claim floor" and can be as simple as

http://floor.example.com?f=1&o=c

Whether having two mechanisms is a good thing, I don't know. Assuming 
that this is ok, they probably must be very different in client 
complexity and message size.

Adam Roach wrote:

> 
> To be clear, Dean's comments were addressing the
> floor control protocol, not the policy control
> protocols. In most cases, floor control is
> significantly more dynamic and real-time than
> policy control. If the floor control protocol
> is inappropriately large, there are concerns that
> the user experience on wireless networks will be
> inadequate. For example, turnaround time from
> requesting an empty floor to receiving notification
> that it has been granted can't take too long,
> or users will become frustrated and potentially
> confused.
> 
> That said, we haven't yet established whether XML
> is inappropriately heavy for floor control. I expect
> that further work on the floor control protocol will
> include an analysis of the issue.

From: "Steve Fisher" <[email-masked]>
To: "'Rohan Mahy'" <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Tue, 15 Jul 2003 17:58:21 -0400
Importance: Normal
Cc: "'IETF XCON Discussion List \(E-mail\)'" <[email-masked]>
Sender: [email-masked]

Rohan,

In your response to Eric you state the following goal for xcon:

"The goal is to allow customers to select a 
conferencing application that can work with many vendor's mixers and 
conference servers."

I'm puzzled how this goal can be achieved when the protocol between the
application server and the mixers is explicitly out of scope for xcon?
According to the charter, the following is out of scope: "Protocol used
between the conference controller and the mixer(s)."

Steve

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Adam Roach <[email-masked]>
To: [email-masked],  [email-masked],  [email-masked]
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 01:56:32 -0500
Sender: [email-masked]

[email-masked] [mailto:[email-masked]] writes:

> Dean made a statement during the XCON BOF that the wireless 
> guys (to which I count myself) do not want XML as it would 
> use to much bandwidth. That is in fact not true - there were 
> requirements expressed that XML is the preferred solution for 
> coding e.g. CPCP

To be clear, Dean's comments were addressing the
floor control protocol, not the policy control
protocols. In most cases, floor control is
significantly more dynamic and real-time than
policy control. If the floor control protocol
is inappropriately large, there are concerns that
the user experience on wireless networks will be
inadequate. For example, turnaround time from
requesting an empty floor to receiving notification
that it has been granted can't take too long,
or users will become frustrated and potentially
confused.

That said, we haven't yet established whether XML
is inappropriately heavy for floor control. I expect
that further work on the floor control protocol will
include an analysis of the issue.

/a
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Tue, 15 Jul 2003 16:21:26 -0400
From: Jonathan Rosenberg <[email-masked]>
Organization: dynamicsoft
To: "Drage, Keith (Keith)" <[email-masked]>
Subject: Re: [XCON] 3GPP Requirements on CPCP
Cc: [email-masked]
Sender: [email-masked]

One of the differences between SIP and HTTP is that HTTP tends to have 
much fewer mandatory headers. As such, I would expect that when used 
in XCAP, there would be few headers, probably just Content-Type. In 
that case, one option is to perform compression on just the body. This 
is reasonably efficient when the body represents a much larger 
percentage of the overall byte count, compared to headers. For that, 
you can using the existing HTTP Content-Encoding facilities, using 
something like gzip. This would avoid the need for any additional 
standardization work to compress this stuff.

-Jonathan R.

Drage, Keith (Keith) wrote:

> Independently of any discussion of which protocol is chosen, we do need to consider the implications on the radio interface of any protocol chosen. There would seem to be a number of decisions that it would be appropriate to make in this regard.
> 
> 1)	Do we select/design a lightweight protocol, making efficient use of individual bits, or select/design a rather heavier weight text-based protocol and then compress it. Previous decisions in the SIP area would suggest we go for the latter, but there ought to be some explicit decision in this respect.
> 
> 2)	Assuming that we opt for a protocol that requires compression, do we specify a standard compression algorithm, or do we select SIGCOMP (RFC3320) which allows downloading of the compression algorithm from sender to receiver. Again SIP has selected SIGCOMP as the appropriate protocol to perform compression and that could well be followed here.
> 
> 3)	Assuming SIGCOMP is chosen, is there a need to specificy a dictionary.
> 
> 4)	If a dictionary is specified, then is that dictionary one and the same dictionary as that specified for SIP (see RFC3485) is there a need for a different dictionary. (Note that if a second dictionary is specified, then this presumably increases the information that would need to be stored in a mobile handset, and this is a finite resource.)
> 
> 5)	If compression is supported, is there a need for an indication in the protocol that the entity is willing to use compression, as specified already for SIP (see RFC3486).
> 
> Finally, it would need to be clarified in the XCON group as to which of these decisions should be made by XCON, and which it should let other groups do (e.g. for SIP the choice and design of the SIGCOMP was performed by the ROHC group).
> 
> regards
> 
> Keith
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: 10 July 2003 12:59
>>To: [email-masked]
>>Subject: [XCON] 3GPP Requirements on CPCP
>>
>>
>>Hello,
>>
>>initially I planned to have a short presentation at the 
>>Vienna meeting on 3GPP requirements on CPCP, but 
>>unfortunately it seems that there is no time slot neither in 
>>SIPPING nor XCON which allows going into technical 
>>discussions during this meeting. So I decided to make my 
>>comments on the mailing list.
>>
>>As you know in 3GPP we are planning to adopt the SIP 
>>conferencing solution for the IMS (IP Multimedia Subsystem). 
>>During the last (CN1 WG) meeting we had some discussions on 
>>CPCP and decided that we will also adopt this solution, 
>>although some delegates had some concerns. I therefore got 
>>the task to collect requirements on CPCP, what I did.
>>
>>As always, the resources in wireless devices are a sacred 
>>thing and therefore the main concern was, that CPCP will 
>>introduce a whole new protocol and notation, that needs to be 
>>implemented "just" for CPCP. Therefore the main issues are:
>>
>>1) that CPCP makes use of an notation mechanism that is 
>>already used within the IMS / SIP protocol. We think that XML 
>>is the way forward here. 
>>
>>2) that CPCP makes use of a protocol that is already used in 
>>state-of-the-art wireless devices. As SIP is not an option 
>>here, we very much favour HTTP, as this is implemented in 
>>every new mobile phone model.
>>
>>As the 3GPP architecture sees the protocols for any sort of 
>>application specific data manipulation over the same (Ut) 
>>interface, we also favour the approach to harmonize the data 
>>manipulation solutions as much as possible. I am aware that 
>>CPCP is more than just data manipulation, nevertheless there 
>>are very similar concepts in e.g. Presence DM and CPCP. As 
>>the IMS will also include (SIMPLE based) Presence and 
>>Presence Data Manipulation, we also see the need
>>
>>3) that CPCP and Presence Data Manipulation solution must be 
>>aligned, in order to re-use as much functionality as possible.
>>
>>This is also important, as we see lots of services in the 
>>future, which will also require Data Manipulation via the Ut 
>>interface - we want these solutions harmonized if possible. 
>>The XCAP proposal as currently discussed in SIMPLE seems to 
>>be the right way forward here. 
>>
>>Finally there is a need that the UE gets aware of the CPCP 
>>server. This might be outside of the scope of XCON, maybe 
>>more related to SIPPING, but as it is related to this issue, 
>>I would like to see it also listed:
>>
>>4) There must be a way for the UE to get aware of the address 
>>of a CPCP server (or any other server which allows the UE to 
>>perform data manipulation).
>>
>>If the group agrees, I would reformulate these requirements 
>>into "requirements language", so that they can be added to 
>>CPCP requirements draft (draft-koskelainen-xcon-cpcp-reqs-00.txt). 
>>
>>Thank you and best regards
>>Georg
>>
>>
>>_______________________________________________
>>XCON mailing list
>>[email-masked]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Tue, 15 Jul 2003 04:45:38 -0700
Subject: Re: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
To: "Eric Burger" <[email-masked]>
From: Rohan Mahy <[email-masked]>
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

On Monday, July 14, 2003, at 08:09 AM, Eric Burger wrote:
> REQ-E4
> Hidden and anonymous users are two different things.  I would split 
> the requirement.

I would like to second Eric's comment here.  I asked for this at one 
point but I think it fell through the cracks.

thanks,
-rohan

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Tue, 15 Jul 2003 04:40:42 -0700
Subject: Re: [XCON] Media Policy in Conferencing Framework
To: "Eric Burger" <[email-masked]>
From: Rohan Mahy <[email-masked]>
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

On Monday, July 14, 2003, at 08:09 AM, Eric Burger wrote:

> [on XCON list, even though a SIPPING draft]
>
> draft-ietf-sipping-conferencing-framework-00 spends many pages on 
> media aspects of conference policy and on media policy itself.
>
> First question: what requirements in the requirements document 
> (draft-ietf-sipping-conferencing-requirements-00) do these sections 
> tie back to?
>
> For example, section 4.6, Conference Policy, is the *definition* of a 
> conferencing application.  I don't think we're ready to say that 
> conferencing applications are obsolete.  I doubt Polycom, Radvision, 
> Ubiquity, Spectel, or Voyant would agree.  Conferencing applications 
> are extremely difficult to develop.  Much of the intellectual 
> challenge is in the user interface.  Getting rid of packaged 
> conference applications so end users can create arbitrarily complex 
> media plumbing and manipulation is not likely to succeed.

Eric,

I agree that conferencing applications are hard to build.  This is 
exactly why we should split these apps from the actual conference and 
media policy underneath. The goal is to allow customers to select a 
conferencing application that can work with many vendor's mixers and 
conference servers.  So Acme Underwriting might decide it likes a 
conferencing application from Voyant, (because they liked the interface 
best) but wants to run the application with Snowshore, Cisco, and 
Microsoft conference servers. (for example).  Also, a company for which 
conferencing is business critical may develop (by hiring a contractor 
or using internal IT development resources) a company-specific 
conferencing application.  A good example might be a financial trading 
call center.  They can focus on the details of the media and 
authorization policies and the user interface, but they don't need to 
build a general purpose mixing engine, a focus, etc..

> Let's compare this to another user language, CPL.  The primitives and 
> model of CPL are oriented around the user's experience, and it is in 
> the user's terms.  The exposition of conference policy and media 
> policy are in the terms of a conference platform developer.  While one 
> can argue about whether Joe Six-Pack will write their own CPL scripts, 
> one could expect a real third-party CPL market happening.  I cannot 
> ever envision Joe Six-Pack writing their own conferencing application. 
>  Moreover, I cannot envision anyone getting economic returns from 
> building, e.g., only the user interface on top of half of a 
> conferencing application (unless the bridge manufacturers are planning 
> on giving away their stuff, which isn't very likely).
>
> Section 5.10 describes very convoluted procedures for replumbing the 
> conference to play an announcement.  Most application developers just 
> want to say, "play a prompt to leg X".  They don't want to say, 
> "reconfigure the mixer to be one user smaller, disconnect X, allocate 
> a player, connect the player to X, start the player, when the player 
> is done, disconnect X from the player, deallocate the player, 
> reconfigure the mixer to be one user larger, and reconnect X."

First, I think you are missing some of the logical aspects of media 
policy.  To play a prompt to one user (or a subset of the users), it 
should be sufficient logically to create a subconference for the prompt 
(1 step) and move the user into it.  When the prompt is done, the 
subconference ends automatically and the user is returned to their 
original conference (0 steps).  To play a prompt to the entire 
conference in most cases, you just add the prompt as a participant to 
the conference.

Second, I think your APIs *will* have functions such as "play a prompt 
to user x", but I think these names can become ambiguous as you try to 
do more complex things.  I believe these APIs can just invoke media 
policy control commands, and this is pretty straightforward.

> On another topic, I don't see floor control being related at all to 
> mixing topology.  That presupposes the policy being done by plumbing 
> instead of having the client simply say what it wants to do.

You may be missing something that is unclear in the framework or in the 
media policy document. When the creator of a conference creates a media 
policy that includes floor control, it connects the logical holder(s) 
of floor to the input of the mix. As different users get the floor, the 
policy does not change.  You don't have to redo any plumbing when you 
switch floor holders.

> Likewise, who would decide to change conference modes on the fly 
> without a vendor-supplied application (section 6.4)?

a non-mixing vendor supplied application (which could be written by a 
different conference vendor) could decide to introduce a sidebar or 
switch between a media policy oriented towards presentation mode to 
panel mode to discussion mode.

> This really comes to my key point.  Who is the consumer of this 
> protocol?  By "consumer", I mean who will write the client and who 
> will write the server?  If they are not by different people, there 
> isn't much value for standardization.

see above..

> For that matter, plumbing and media manipulation do not meet the 
> guideline proposed in draft-ietf-sipping-cc-framework-02, that the 
> primitives be participant-oriented, not media relationship-oriented.

actually they do.  I could use media policy to decide who participants 
are in which conversation space (participant-oriented), but I do not 
specify which call legs go where or how many or which type of mixers 
are controlled by the focus.

thanks,
-rohan

>
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
Date: Mon, 14 Jul 2003 14:46:20 -0400
From: "Eric Burger" <[email-masked]>
To: "Michael Hammer" <[email-masked]>
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

Exactly -- a conferencing protocol would not need to deal with the key distribution.

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Mon, July 14, 2003 11:33 AM
To: Eric Burger
Cc: IETF XCON Discussion List (E-mail)
Subject: Re: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00

At 11:09 AM 7/14/2003 -0400, Eric Burger wrote:

For example, there is no key distribution with public keys.

Not sure I understand this statement.  What is the point of putting public keys into the DNS, if not distribution?

Mike

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Even, Roni" <[email-masked]>
To: "'Eric Burger'" <[email-masked]>,  "IETF XCON Discussion List (E-mail)" <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Mon, 14 Jul 2003 21:22:31 +0300
Sender: [email-masked]

Eric,
As one of the companies having conferencing bridge we have third parties
developing conferencing application based on our API. This is the same API
we use for our conferencing application. That includes creating conferences
, adding users, defining the mixing modes and even forcing views. I would
imagine that those application developers would like to have a common
protocol for those applications. The reason for application development is
to enable them to create services according to their requirements.
Thanks
Roni Even
Polycom

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Monday, July 14, 2003 6:10 PM
To: IETF XCON Discussion List (E-mail)
Subject: [XCON] Media Policy in Conferencing Framework

[on XCON list, even though a SIPPING draft]

draft-ietf-sipping-conferencing-framework-00 spends many pages on media
aspects of conference policy and on media policy itself.

First question: what requirements in the requirements document
(draft-ietf-sipping-conferencing-requirements-00) do these sections tie back
to?

For example, section 4.6, Conference Policy, is the *definition* of a
conferencing application.  I don't think we're ready to say that
conferencing applications are obsolete.  I doubt Polycom, Radvision,
Ubiquity, Spectel, or Voyant would agree.  Conferencing applications are
extremely difficult to develop.  Much of the intellectual challenge is in
the user interface.  Getting rid of packaged conference applications so end
users can create arbitrarily complex media plumbing and manipulation is not
likely to succeed.

Let's compare this to another user language, CPL.  The primitives and model
of CPL are oriented around the user's experience, and it is in the user's
terms.  The exposition of conference policy and media policy are in the
terms of a conference platform developer.  While one can argue about whether
Joe Six-Pack will write their own CPL scripts, one could expect a real
third-party CPL market happening.  I cannot ever envision Joe Six-Pack
writing their own conferencing application.  Moreover, I cannot envision
anyone getting economic returns from building, e.g., only the user interface
on top of half of a conferencing application (unless the bridge
manufacturers are planning on giving away their stuff, which isn't very
likely).

Section 5.10 describes very convoluted procedures for replumbing the
conference to play an announcement.  Most application developers just want
to say, "play a prompt to leg X".  They don't want to say, "reconfigure the
mixer to be one user smaller, disconnect X, allocate a player, connect the
player to X, start the player, when the player is done, disconnect X from
the player, deallocate the player, reconfigure the mixer to be one user
larger, and reconnect X."

On another topic, I don't see floor control being related at all to mixing
topology.  That presupposes the policy being done by plumbing instead of
having the client simply say what it wants to do.

Likewise, who would decide to change conference modes on the fly without a
vendor-supplied application (section 6.4)?

This really comes to my key point.  Who is the consumer of this protocol?
By "consumer", I mean who will write the client and who will write the
server?  If they are not by different people, there isn't much value for
standardization.

For that matter, plumbing and media manipulation do not meet the guideline
proposed in draft-ietf-sipping-cc-framework-02, that the primitives be
participant-oriented, not media relationship-oriented.

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Mon, 14 Jul 2003 11:33:21 -0400
To: "Eric Burger" <[email-masked]>
From: Michael Hammer <[email-masked]>
Subject: Re: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

At 11:09 AM 7/14/2003 -0400, Eric Burger wrote:
>For example, there is no key distribution with public keys.

Not sure I understand this statement.  What is the point of putting public 
keys into the DNS, if not distribution?

Mike
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Drage, Keith (Keith)" <[email-masked]>
To: [email-masked],  [email-masked]
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Fri, 11 Jul 2003 17:08:34 +0100
Sender: [email-masked]

Independently of any discussion of which protocol is chosen, we do need to consider the implications on the radio interface of any protocol chosen. There would seem to be a number of decisions that it would be appropriate to make in this regard.

1)	Do we select/design a lightweight protocol, making efficient use of individual bits, or select/design a rather heavier weight text-based protocol and then compress it. Previous decisions in the SIP area would suggest we go for the latter, but there ought to be some explicit decision in this respect.

2)	Assuming that we opt for a protocol that requires compression, do we specify a standard compression algorithm, or do we select SIGCOMP (RFC3320) which allows downloading of the compression algorithm from sender to receiver. Again SIP has selected SIGCOMP as the appropriate protocol to perform compression and that could well be followed here.

3)	Assuming SIGCOMP is chosen, is there a need to specificy a dictionary.

4)	If a dictionary is specified, then is that dictionary one and the same dictionary as that specified for SIP (see RFC3485) is there a need for a different dictionary. (Note that if a second dictionary is specified, then this presumably increases the information that would need to be stored in a mobile handset, and this is a finite resource.)

5)	If compression is supported, is there a need for an indication in the protocol that the entity is willing to use compression, as specified already for SIP (see RFC3486).

Finally, it would need to be clarified in the XCON group as to which of these decisions should be made by XCON, and which it should let other groups do (e.g. for SIP the choice and design of the SIGCOMP was performed by the ROHC group).

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 10 July 2003 12:59
> To: [email-masked]
> Subject: [XCON] 3GPP Requirements on CPCP
> 
> 
> Hello,
> 
> initially I planned to have a short presentation at the 
> Vienna meeting on 3GPP requirements on CPCP, but 
> unfortunately it seems that there is no time slot neither in 
> SIPPING nor XCON which allows going into technical 
> discussions during this meeting. So I decided to make my 
> comments on the mailing list.
> 
> As you know in 3GPP we are planning to adopt the SIP 
> conferencing solution for the IMS (IP Multimedia Subsystem). 
> During the last (CN1 WG) meeting we had some discussions on 
> CPCP and decided that we will also adopt this solution, 
> although some delegates had some concerns. I therefore got 
> the task to collect requirements on CPCP, what I did.
> 
> As always, the resources in wireless devices are a sacred 
> thing and therefore the main concern was, that CPCP will 
> introduce a whole new protocol and notation, that needs to be 
> implemented "just" for CPCP. Therefore the main issues are:
> 
> 1) that CPCP makes use of an notation mechanism that is 
> already used within the IMS / SIP protocol. We think that XML 
> is the way forward here. 
> 
> 2) that CPCP makes use of a protocol that is already used in 
> state-of-the-art wireless devices. As SIP is not an option 
> here, we very much favour HTTP, as this is implemented in 
> every new mobile phone model.
> 
> As the 3GPP architecture sees the protocols for any sort of 
> application specific data manipulation over the same (Ut) 
> interface, we also favour the approach to harmonize the data 
> manipulation solutions as much as possible. I am aware that 
> CPCP is more than just data manipulation, nevertheless there 
> are very similar concepts in e.g. Presence DM and CPCP. As 
> the IMS will also include (SIMPLE based) Presence and 
> Presence Data Manipulation, we also see the need
> 
> 3) that CPCP and Presence Data Manipulation solution must be 
> aligned, in order to re-use as much functionality as possible.
> 
> This is also important, as we see lots of services in the 
> future, which will also require Data Manipulation via the Ut 
> interface - we want these solutions harmonized if possible. 
> The XCAP proposal as currently discussed in SIMPLE seems to 
> be the right way forward here. 
> 
> Finally there is a need that the UE gets aware of the CPCP 
> server. This might be outside of the scope of XCON, maybe 
> more related to SIPPING, but as it is related to this issue, 
> I would like to see it also listed:
> 
> 4) There must be a way for the UE to get aware of the address 
> of a CPCP server (or any other server which allows the UE to 
> perform data manipulation).
> 
> If the group agrees, I would reformulate these requirements 
> into "requirements language", so that they can be added to 
> CPCP requirements draft (draft-koskelainen-xcon-cpcp-reqs-00.txt). 
> 
> Thank you and best regards
> Georg
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Fri, 11 Jul 2003 13:37:08 +0300
From: [email-masked]
To: [email-masked],  [email-masked]
Sender: [email-masked]

Hello Alan,

thanks for your reponse - here are some comments to it.

> HTTP may be used as transport but it will not be the actual 
> protocol.  And 
> you are correct in saying that CPCP is much more than just a data 
> manipulation protocol.

Yes, I was unclear in that statement - sorry for that. What is required is, that we do not go for the next protocol that is required in order to make SIP services work and that is not used / implemented for any other SIP means. This would mean "just another protocol stack" in the UE and we should really try to avoid that. This might not be a requirement for an acutal functionality, but nevertheless it is a reasonable issue and should be taken into account.

> I think it is desirable for alignment, but not a strict 
> requirement.  

For 3GPP it is a strict requirement towards the solution. I would maybe express it as: This is not the only requirement and we have to see if we achieve to satisfy all (CPCP) requirements or if there might be some contradiction between them.

> If 
> their requirements point to a common solution, then that's 
> great.  
> Just as 
> an aside, my personal view is that the CPCP side of things 
> (as opposed to 
> the media policy) is much more likely to be useful for scheduling 
> applications and automata than for handsets.

Well, for IMS it was decided to use CPCP and we have good reasons to do so. First of all the service integration in the handset will of course become better in the future, but nevertheless needs to stay within a reasonable amount of resource usage. So I do not think that only specific entities will implement CPCP - the possiblities to create conferences, mange the dial-out list, give/take rights, expel users are very useful for handsets. So therefore I would regard the "handset related" requirements as also valid.

Best regards and see you in Vienna,
Georg

> -----Original Message-----
> From: ext Alan Johnston [mailto:[email-masked]]
> Sent: 10 July, 2003 16:40
> To: Mayer Georg (NMP/Helsinki); [email-masked]
> Subject: Re: [XCON] 3GPP Requirements on CPCP
> 
> 
> Hi Georg,
> 
> Thanks for your comments.  See mine below.
> 
> Thanks,
> Alan Johnston
> MCI
> 
> At 02:58 PM 7/10/2003 +0300, [email-masked] wrote:
> >Hello,
> >
> >initially I planned to have a short presentation at the 
> Vienna meeting on 
> >3GPP requirements on CPCP, but unfortunately it seems that 
> there is no 
> >time slot neither in SIPPING nor XCON which allows going 
> into technical 
> >discussions during this meeting. So I decided to make my 
> comments on the 
> >mailing list.
> >
> >As you know in 3GPP we are planning to adopt the SIP 
> conferencing solution 
> >for the IMS (IP Multimedia Subsystem). During the last (CN1 
> WG) meeting we 
> >had some discussions on CPCP and decided that we will also 
> adopt this 
> >solution, although some delegates had some concerns. I 
> therefore got the 
> >task to collect requirements on CPCP, what I did.
> >
> >As always, the resources in wireless devices are a sacred thing and 
> >therefore the main concern was, that CPCP will introduce a whole new 
> >protocol and notation, that needs to be implemented "just" for CPCP. 
> >Therefore the main issues are:
> >
> >1) that CPCP makes use of an notation mechanism that is already used 
> >within the IMS / SIP protocol. We think that XML is the way 
> forward here.
> 
> I have not seen any non-XML encoded proposals, so this seems OK.
> 
> >2) that CPCP makes use of a protocol that is already used in 
> >state-of-the-art wireless devices. As SIP is not an option 
> here, we very 
> >much favour HTTP, as this is implemented in every new mobile 
> phone model.
> >
> >As the 3GPP architecture sees the protocols for any sort of 
> application 
> >specific data manipulation over the same (Ut) interface, we 
> also favour 
> >the approach to harmonize the data manipulation solutions as much as 
> >possible. I am aware that CPCP is more than just data manipulation, 
> >nevertheless there are very similar concepts in e.g. 
> Presence DM and CPCP. 
> >As the IMS will also include (SIMPLE based) Presence and 
> Presence Data 
> >Manipulation, we also see the need
> 
> HTTP may be used as transport but it will not be the actual 
> protocol.  And 
> you are correct in saying that CPCP is much more than just a data 
> manipulation protocol.
> 
> >3) that CPCP and Presence Data Manipulation solution must be 
> aligned, in 
> >order to re-use as much functionality as possible.
> 
> I think it is desirable for alignment, but not a strict 
> requirement.  If 
> their requirements point to a common solution, then that's 
> great.  Just as 
> an aside, my personal view is that the CPCP side of things 
> (as opposed to 
> the media policy) is much more likely to be useful for scheduling 
> applications and automata than for handsets.
> 
> >This is also important, as we see lots of services in the 
> future, which 
> >will also require Data Manipulation via the Ut interface - 
> we want these 
> >solutions harmonized if possible. The XCAP proposal as 
> currently discussed 
> >in SIMPLE seems to be the right way forward here.
> >
> >Finally there is a need that the UE gets aware of the CPCP 
> server. This 
> >might be outside of the scope of XCON, maybe more related to 
> SIPPING, but 
> >as it is related to this issue, I would like to see it also listed:
> 
> The current plan is that a user agent will learn the policy 
> URIs using the 
> conference package - at the same time that the initial roster 
> is delivered.
> 
> 
> >4) There must be a way for the UE to get aware of the 
> address of a CPCP 
> >server (or any other server which allows the UE to perform 
> data manipulation).
> >
> >If the group agrees, I would reformulate these requirements into 
> >"requirements language", so that they can be added to CPCP 
> requirements 
> >draft (draft-koskelainen-xcon-cpcp-reqs-00.txt).
> >
> >Thank you and best regards
> >Georg
> >
> >
> >_______________________________________________
> >XCON mailing list
> >[email-masked]
> >http://www.softarmor.com/mailman/listinfo/xcon
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 10 Jul 2003 08:40:12 -0500
From: Alan Johnston <[email-masked]>
Subject: Re: [XCON] 3GPP Requirements on CPCP
To: [email-masked],  [email-masked]
Sender: [email-masked]

Hi Georg,

Thanks for your comments.  See mine below.

Thanks,
Alan Johnston
MCI

At 02:58 PM 7/10/2003 +0300, [email-masked] wrote:
>Hello,
>
>initially I planned to have a short presentation at the Vienna meeting on 
>3GPP requirements on CPCP, but unfortunately it seems that there is no 
>time slot neither in SIPPING nor XCON which allows going into technical 
>discussions during this meeting. So I decided to make my comments on the 
>mailing list.
>
>As you know in 3GPP we are planning to adopt the SIP conferencing solution 
>for the IMS (IP Multimedia Subsystem). During the last (CN1 WG) meeting we 
>had some discussions on CPCP and decided that we will also adopt this 
>solution, although some delegates had some concerns. I therefore got the 
>task to collect requirements on CPCP, what I did.
>
>As always, the resources in wireless devices are a sacred thing and 
>therefore the main concern was, that CPCP will introduce a whole new 
>protocol and notation, that needs to be implemented "just" for CPCP. 
>Therefore the main issues are:
>
>1) that CPCP makes use of an notation mechanism that is already used 
>within the IMS / SIP protocol. We think that XML is the way forward here.

I have not seen any non-XML encoded proposals, so this seems OK.

>2) that CPCP makes use of a protocol that is already used in 
>state-of-the-art wireless devices. As SIP is not an option here, we very 
>much favour HTTP, as this is implemented in every new mobile phone model.
>
>As the 3GPP architecture sees the protocols for any sort of application 
>specific data manipulation over the same (Ut) interface, we also favour 
>the approach to harmonize the data manipulation solutions as much as 
>possible. I am aware that CPCP is more than just data manipulation, 
>nevertheless there are very similar concepts in e.g. Presence DM and CPCP. 
>As the IMS will also include (SIMPLE based) Presence and Presence Data 
>Manipulation, we also see the need

HTTP may be used as transport but it will not be the actual protocol.  And 
you are correct in saying that CPCP is much more than just a data 
manipulation protocol.

>3) that CPCP and Presence Data Manipulation solution must be aligned, in 
>order to re-use as much functionality as possible.

I think it is desirable for alignment, but not a strict requirement.  If 
their requirements point to a common solution, then that's great.  Just as 
an aside, my personal view is that the CPCP side of things (as opposed to 
the media policy) is much more likely to be useful for scheduling 
applications and automata than for handsets.

>This is also important, as we see lots of services in the future, which 
>will also require Data Manipulation via the Ut interface - we want these 
>solutions harmonized if possible. The XCAP proposal as currently discussed 
>in SIMPLE seems to be the right way forward here.
>
>Finally there is a need that the UE gets aware of the CPCP server. This 
>might be outside of the scope of XCON, maybe more related to SIPPING, but 
>as it is related to this issue, I would like to see it also listed:

The current plan is that a user agent will learn the policy URIs using the 
conference package - at the same time that the initial roster is delivered.

>4) There must be a way for the UE to get aware of the address of a CPCP 
>server (or any other server which allows the UE to perform data manipulation).
>
>If the group agrees, I would reformulate these requirements into 
>"requirements language", so that they can be added to CPCP requirements 
>draft (draft-koskelainen-xcon-cpcp-reqs-00.txt).
>
>Thank you and best regards
>Georg
>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 10 Jul 2003 08:42:55 -0500
From: Alan Johnston <[email-masked]>
Subject: Re: [XCON] 3GPP Requirements on CPCP
To: [email-masked],  [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Hi Arjun,

 From the proposed charter is this sentence "[None of the protocols defined 
by this group will be SIP or require SIP extensions.]"  The actual protocol 
has not been decided, but ones discussed include XCAP, SOAP, and XML-RPC.

Some of the functionality of CPCP can be done using SIP (see the SIPPING 
conferencing documents http://ee.wustl.edu/~alan/sip-conf) but the advanced 
functionality being developed for XCON is not suitable to be implemented 
using SIP.

Thanks,
Alan Johnston
MCI

At 08:11 AM 7/10/2003 -0400, [email-masked] wrote:
>Inline, ARC>
>
>2) that CPCP makes use of a protocol that is already used in
>state-of-the-art wireless devices. As SIP is not an option here, we very
>much favour HTTP, as this is implemented in every new mobile phone model.
>
>ARC> I am unclear on this point. My understanding was that till now the
>protocol that would envelope CPCP is still undecided. Was it decided
>recently that SIP is not an option ? My personal preference was to keep a
>single protocol - but I was under the impression this was not yet debated
>over. Would you please clarify ?
>
>regds
>arjun
>
>
>--
>Arjun Roychowdhury @ Hughes Software Systems
>11717 Exploration Lane, Germantown MD 20876
>(O): 301 212 7860
>
>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

To: [email-masked]
Subject: Re: [XCON] 3GPP Requirements on CPCP
From: [email-masked]
Date: Thu, 10 Jul 2003 08:11:47 -0400
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

Inline, ARC>

2) that CPCP makes use of a protocol that is already used in 
state-of-the-art wireless devices. As SIP is not an option here, we very 
much favour HTTP, as this is implemented in every new mobile phone model.

ARC> I am unclear on this point. My understanding was that till now the 
protocol that would envelope CPCP is still undecided. Was it decided
recently that SIP is not an option ? My personal preference was to keep a 
single protocol - but I was under the impression this was not yet debated 
over. Would you please clarify ?

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Thu, 10 Jul 2003 15:20:18 +0300
From: [email-masked]
To: [email-masked]
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

Hello,
 
sorry if I got that wrong - if SIP is still under discussion then this is fine. My intention was _not_ to say "SIP is not an option for 3G". If SIP would fulfill the requirements and would be chosen for CPCP then this would (at least for me) be fine.
 
Thanks and best regards
Georg

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 10 July, 2003 15:12
To: Mayer Georg (NMP/Helsinki)
Cc: [email-masked]; [email-masked]
Subject: Re: [XCON] 3GPP Requirements on CPCP

Inline, ARC> 

2) that CPCP makes use of a protocol that is already used in state-of-the-art wireless devices. As SIP is not an option here, we very much favour HTTP, as this is implemented in every new mobile phone model.

ARC> I am unclear on this point. My understanding was that till now the protocol that would envelope CPCP is still undecided. Was it decided 
recently that SIP is not an option ? My personal preference was to keep a single protocol - but I was under the impression this was not yet debated over. Would you please clarify ? 

regds 
arjun 

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860   

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00
Date: Wed, 2 Jul 2003 09:47:39 +0300
From: [email-masked]
To: [email-masked],  [email-masked]
Cc: [email-masked],  [email-masked]
Sender: [email-masked]

> -----Original Message-----
> From: ext Eunsook Kim [mailto:[email-masked]]
> Sent: Wednesday, July 02, 2003 8:57 AM
> To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> Cc: [email-masked]; Isomaki Markus (NRC/Helsinki);
> [email-masked]; [email-masked]
> Subject: Re: [XCON] Conference Policy Control -comments on
> draft-koskelainen-xcon-xcap-cpcp-usage-00
> 
> 
> Hi Hisham,
> 
> First of all, I'd like to say that I've been also thinking 
> the importance of your document is the idea in this momont. 
> I don't think I misunderstand this point. 
> I did the validation work because I think a valid schema 
> would increase the readibility. 
> (Because of the not-wellformed schema, I had some trouble 
> when I tried to look over 
> if the schema was well delivering your idea. So, I did the 
> validation work, first.)
> 
> Second, I have a few questions on your document as following: 
> 
> 1. Your document is mentioning that CPS lets Focus know the 
> Dial-out List, and then Focus send INVITE to the members in the list,
>     and CPS also have the FOCUS to send BYE when there is a 
> BLOCKED member.
>     However, there is no explanation of HOW the CPS carries 
> the information to the Focus. 
>     I know they are logical entities, but I don't think CPS 
> and Focus are always configutated in local system. 
>     So, I think they need a way to communicate each other.
>     Is this the out of scope of the XCON work? Or, do you 
> remain this work as future work?

It was deliberately left out. I guess this is a questions for the chairs to answer.

> 
> 2. I think we need a field for describing media (or codec) 
> information when a client requests a conference creation.
>     I DON'T mean the negotiation of media. The preference of 
> the client should be considered, I think. 
>     Is the "Conference-media-policy" which is not yet defined 
> for this purpose? 

The dialog and media negotiation is between the CPS (focus) and the participants. Why would the creator care what codecs the other participants use between them and the focus?

In any case, you can read more about media policy in this draft (although I don't think codec preference is part of it:

http://www.ietf.org/internet-drafts/draft-mahy-xcon-media-policy-control-00.txt

The author has been looking into XCAP for this as well.

> 
> 3. This can be minor in the moment, but .......;
>     You defined "Conference-URI", the sub-element of 
> "Conference" as a required element, and 
>     "SIP-URI", the sub-element of the "Conference-URI" is 
> also defined as a required element.
>     However, the conferencing framework document ,and also 
> your document are describing
>     CPS can create the conference URI. In addition, your 
> document mentions the conference URI can be 
>     SIP, SIPS, or TEL URI. 
>     Based on the describtions, I think it is definitely 
> needed to define, but should not be defined as a required one. 

It is required since without it, the conference cannot be addressed. The creator includes it, even though empty, as a way of indicating that it deliberately left it out for the server to fill in (not a mistake). Maybe others have a better answer.

Thanks for the interest in this work

Regards,
Hisham
>     
> 
> I'll appreciate your response.
> 
> Sincerely,
> Eunah
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 01, 2003 10:35 PM
> Subject: RE: [XCON] Conference Policy Control -comments on 
> draft-koskelainen-xcon-xcap-cpcp-usage-00
> 
> 
> > Hi Eunah,
> > 
> > Thanks for the comments and corrections. Your modifications 
> will be taken into consideration.
> > 
> > We actually have not put the schema into a validator yet 
> due to time constraints, but will do as soon as possible.  We 
> felt that the XML validity is not a big issue now, but the 
> community accepting the idea was.
> > 
> > Anyhow, the next version will hopefully have a valid XML schema.
> > 
> > Regards,
> > Hisham
> > 
> > > -----Original Message-----
> > > From: ext Eunsook Kim [mailto:[email-masked]]
> > > Sent: Tuesday, July 01, 2003 3:23 PM
> > > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham 
> (NMP/Helsinki)
> > > Cc: [email-masked]; Isomaki Markus (NRC/Helsinki);
> > > [email-masked]; [email-masked]
> > > Subject: Re: [XCON] Conference Policy Control -comments on
> > > draft-koskelainen-xcon-xcap-cpcp-usage-00
> > > 
> > > 
> > > Hi Petri, and Hisham
> > > 
> > > I went over XCAP and the related documents and admit that it 
> > > gives simple and light method to manipulate conference policy. :-)
> > > I also have looked over your document and the defined XML 
> > > schema, and found a lot of syntax errors and several schema 
> > > validation errors.
> > > I tried to correct them, and attach the schema file, which I 
> > > get the successful validation message by running it into 
> the XMLSPY. 
> > > Currently, I changed or added some of definition to get a 
> > > valid schema. 
> > > I tried to read your intention as possible as I can, but 
> > > please let me know if the corrections doesn't carry well on 
> > > your intention.
> > >  
> > > -----------------
> > > The brief note of the errors is as following:
> > > 
> > > 1. Namespace should be defined for 'conference-policy' in 
> > > order to reuse types and elements defined in the document.
> > > 
> > > [[Syntax errors]]
> > > 
> > > 2. Comment type should be <!--   --> instead <! >
> > > 
> > > 3. There are many cases where definitions are unappropriately 
> > > ended. I cannot list all of them here; give an example:
> > >           <xsd:simpleType name="Visibility-type"/>   <!-- '/' 
> > > not necessary -->
> > >                      <xsd:restriction base="xsd:string">
> > >                                 <xsd:enumeration value="visible"/>
> > >                                 <xsd:enumeration 
> value="invisible"/>
> > >                      </xsd:restriction>
> > >             </xsd:simpleType>
> > > 
> > > 4.And, there are some mismatched or missed or redundant end tags.
> > >          ex)       <xsd:element name="Host-info">  <!-- in 
> > > "Conference-time" element -->
> > >                                <xsd:complexType>
> > >                                        <xsd:sequence>
> > >                                                <xsd:element 
> > > name="SIP-URI"  type="xsd:anyURI" use="required"/>
> > >                                                 .......... 
> > > (some elements)
> > >                                         <xsd:sequence> <!-- 
> > > you need to close the "sequence" with </xsd:sequence> -->
> > >                                        <xsd:sequence>  <!-- 
> > > and, you don't need one of the two "xsd:sequence" -->
> > >                               <xsd:complexType>
> > >                     </xsd:element>
> > > 
> > > [[Unvalid Schema Definition Errors]]
> > > 
> > > 5. You use [use="required"] severral times in definition of 
> > > elements, which is not appropriate. minOccurs="1" can be 
> > > used, instead.
> > > 
> > > 6. in your definition)      <xsd:element 
> name="Security-mechanism">
> > >                                        <xsd:complexType>
> > >                                              <xsd:attribute 
> > > value="TLS"  type="xsd:boolean" default="false"/>
> > >                                              <xsd:attribute 
> > > value="S-MIME"  type="xsd:boolean" default="false"/>
> > >                                        </xsd:complexType>
> > >                                   </xsd:element>
> > > 
> > >    I got an error indicating unappropriate use of "value" in 
> > > attribute;
> > >    I got the validation error in the following definition. I 
> > > defined the type of Security-mechanism, and reuse it for the 
> > > definition.
> > >    Please let me know if it is different from your intention. 
> > > Then, I'll correct it as your intention. 
> > > 
> > > 
> > > 7.          <xsd:element name="Authorization-mechanism">
> > >                <xsd:complexType>
> > >                      <xsd:restriction base="xsd:string">
> > >                           <xsd:enumeration value="Digest"/>
> > >                           <xsd:enumeration value="None"/>
> > >                      </xsd:restriction>
> > >                      <xsd:attribute name="Password"  
> > > type="xsd:string"/>
> > >               </xsd:complexType>
> > > 
> > >      I got an error indicating wrong use of "restrction" 
> > > based enumeration value in a complexType. 
> > >      I tried to define the type of Authorixation-type for the 
> > > enumeration values.
> > > 
> > > 
> > > 8.           <xsd:element name="ACL">
> > >                         <xsd:complexType>
> > >                                  <xsd:sequence>
> > >                                            <xsd:element 
> > > name="ACL-target-URI" type="xsd:anyURI"  use="required" 
> minOccurs="1" 
> > >                                                
> > > MaxOccurs="unbounded"/>  
> > >                                                          
> > > <xsd:complexType>
> > >                                                               
> > >      <xsd:attribute name="Access-type"  type="Access-mode"/>
> > >                                                          
> > > </xsd:complexType>
> > >                                  </xsd:sequence>
> > >                         </xsd:complexType>
> > >                </xsd:element>
> > > 
> > >      Over the definition, the closed tag of "ACL-target-URI" 
> > > element followed by MaxOccurs="unbounded" is not correct 
> here, right? 
> > >     I guess you'd like to make ACL-target-URI have an 
> > > attribute, am I correct?
> > >      Anyway, I got an error indicating unappropriate use of 
> > > attribute here, so I changed "ACL" element to the form of  
> > > "PCL" and "DL" in this moment, but it is not your intention, 
> > > please let me know.
> > > 
> > > ------------------
> > > 
> > > I hope this will be helpful. 
> > >    
> > > Sincerely, 
> > > Eunah
> > > 
> > > 
> > > 
> > > 
> > > >
> > > >
> > > > ----- Original Message ----- 
> > > > From: [email-masked] 
> > > > To: [email-masked] ; [email-masked] 
> > > > Cc: [email-masked] ; [email-masked] ; 
> > > [email-masked] 
> > > > Sent: Friday, June 27, 2003 10:51 PM
> > > > Subject: RE: [XCON] Conference Policy Control 
> > > > 
> > > > 
> > > > Hi Eunah,
> > > > 
> > > > Thanks for the input. CPCP is very different from floor 
> > > control so we don't need to have same protocol
> > > > for these (besides, XCAP is already used for presence-list 
> > > manipulation which is similar to conf policy manipulation etc).
> > > > 
> > > > If you can provide input to CPCP (e.g. what parameters 
> > > should be included in the policy, or finding errors in 
> XML Schema) 
> > > > that would be highly appreciated.  
> > > > 
> > > > Thanks,
> > > > Petri
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: ext Eunsook Kim [mailto:[email-masked]]
> > > >>Sent: 27 June, 2003 16:44
> > > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri 
> (NRC/Tampere)
> > > >>Cc: [email-masked]; Isomaki Markus 
> (NRC/Helsinki); JongHwa
> > > >>Subject: Re: [XCON] Conference Policy Control 
> > > >>
> > > >>
> > > >>Hisham,
> > > >>
> > > >>Thanks a lot for your response. 
> > > >>
> > > >>I've chosen SOAP for acessing server elements of conference 
> > > policy control, because  it is a well-known standardized 
> protocol. 
> > > >>Besides, I believe there is a close relationship between 
> > > conference policy and floor controls, and I think that it 
> > > would be good for the two >>mechanisms to use the same protocol. 
> > > >>As you know, Xioatao and Petri have already proposed a 
> > > floor control draft using SOAP, 
> > > >>so, I've prototyped a few basic functions of policy control 
> > > using SOAP, and wrote my draft. 
> > > >>However, SOAP is just one of the methods to allow client to 
> > > access policy server information, and 
> > > >>I'm willing to do it by using XCAP, too
> > > >>
> > > >>I think,  the main focus of this work is not if it should 
> > > be SOAP or XCAP. 
> > > >>In my opinion, it is more important to design well-formed 
> > > schema for policy control operations which can be 
> > > standardized, and I think the >>conference design team has 
> > > been doing very good job in this point of view. And, as the 
> > > one who is very interested in and working on this area, >>I'm 
> > > very happy to hear the XCON bof announcement, and I'll be 
> > > very happy if I can help or contribute some parts on the 
> > > works of design team.
> > > >>
> > > >>I'll go over all the XCON drafts again, and I would like to 
> > > discuss on this topic with you more in the mailing list, if 
> > > you'd like to.
> > > >>
> > > >>I appreciate your response again.
> > > >>
> > > >>Yours faithfully, Eunah
> > > >>
> > > >>
> > > >>
> > > >>>----- Original Message ----- 
> > > >>>From: [email-masked] 
> > > >>>To: [email-masked] ; [email-masked] 
> > > >>>Cc: [email-masked] ; [email-masked] 
> > > >>>Sent: Friday, June 27, 2003 3:24 PM
> > > >>>Subject: RE: [XCON] Conference Policy Control 
> > > >>>
> > > >>>
> > > >>>Eunah,
> > > >>>
> > > >>>We appreciate your enthusiasm about the conferencing work.
> > > >>>
> > > >>>Your proposal so makes use of SOAP as a solution. To be 
> > > honest, our interest in SOAP as a solution for conference 
> > > policy protocol is very >>>minimal. That's why we chose XCAP, 
> > > its simple and much lighter to implement than SOAP.
> > > >>>
> > > >>>If you feel that your proposal is the superior one, please 
> > > feel free to involve yourself in the soon newly formed IETF 
> > > working group, named >>>XCON, specifically designed to 
> > > produce such conferencing protocols. The conferencing work so 
> > > far has been done in a closed design team >>>where the XCAP 
> > > has so far been well accepted as the conference policy solution.
> > > >>>
> > > >>>Much appreciated,
> > > >>>Hisham
> > > 
> > > 
> > > 
> > 
> > 
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Eunsook Kim" <[email-masked]>
To: [email-masked],  [email-masked]
Subject: Re: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00
Date: Wed, 2 Jul 2003 14:57:26 +0900
Organization: ETRI
Cc: [email-masked],  [email-masked]
Reply-To: Eunsook Kim <[email-masked]>
Sender: [email-masked]

Hi Hisham,

First of all, I'd like to say that I've been also thinking the importance of your document is the idea in this momont. 
I don't think I misunderstand this point. 
I did the validation work because I think a valid schema would increase the readibility. 
(Because of the not-wellformed schema, I had some trouble when I tried to look over 
if the schema was well delivering your idea. So, I did the validation work, first.)

Second, I have a few questions on your document as following: 

1. Your document is mentioning that CPS lets Focus know the Dial-out List, and then Focus send INVITE to the members in the list,
    and CPS also have the FOCUS to send BYE when there is a BLOCKED member.
    However, there is no explanation of HOW the CPS carries the information to the Focus. 
    I know they are logical entities, but I don't think CPS and Focus are always configutated in local system. 
    So, I think they need a way to communicate each other.
    Is this the out of scope of the XCON work? Or, do you remain this work as future work?

2. I think we need a field for describing media (or codec) information when a client requests a conference creation.
    I DON'T mean the negotiation of media. The preference of the client should be considered, I think. 
    Is the "Conference-media-policy" which is not yet defined for this purpose? 

3. This can be minor in the moment, but .......;
    You defined "Conference-URI", the sub-element of "Conference" as a required element, and 
    "SIP-URI", the sub-element of the "Conference-URI" is also defined as a required element.
    However, the conferencing framework document ,and also your document are describing
    CPS can create the conference URI. In addition, your document mentions the conference URI can be 
    SIP, SIPS, or TEL URI. 
    Based on the describtions, I think it is definitely needed to define, but should not be defined as a required one. 

I'll appreciate your response.

Sincerely,
Eunah

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 01, 2003 10:35 PM
Subject: RE: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00

> Hi Eunah,
> 
> Thanks for the comments and corrections. Your modifications will be taken into consideration.
> 
> We actually have not put the schema into a validator yet due to time constraints, but will do as soon as possible.  We felt that the XML validity is not a big issue now, but the community accepting the idea was.
> 
> Anyhow, the next version will hopefully have a valid XML schema.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: ext Eunsook Kim [mailto:[email-masked]]
> > Sent: Tuesday, July 01, 2003 3:23 PM
> > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham (NMP/Helsinki)
> > Cc: [email-masked]; Isomaki Markus (NRC/Helsinki);
> > [email-masked]; [email-masked]
> > Subject: Re: [XCON] Conference Policy Control -comments on
> > draft-koskelainen-xcon-xcap-cpcp-usage-00
> > 
> > 
> > Hi Petri, and Hisham
> > 
> > I went over XCAP and the related documents and admit that it 
> > gives simple and light method to manipulate conference policy. :-)
> > I also have looked over your document and the defined XML 
> > schema, and found a lot of syntax errors and several schema 
> > validation errors.
> > I tried to correct them, and attach the schema file, which I 
> > get the successful validation message by running it into the XMLSPY. 
> > Currently, I changed or added some of definition to get a 
> > valid schema. 
> > I tried to read your intention as possible as I can, but 
> > please let me know if the corrections doesn't carry well on 
> > your intention.
> >  
> > -----------------
> > The brief note of the errors is as following:
> > 
> > 1. Namespace should be defined for 'conference-policy' in 
> > order to reuse types and elements defined in the document.
> > 
> > [[Syntax errors]]
> > 
> > 2. Comment type should be <!--   --> instead <! >
> > 
> > 3. There are many cases where definitions are unappropriately 
> > ended. I cannot list all of them here; give an example:
> >           <xsd:simpleType name="Visibility-type"/>   <!-- '/' 
> > not necessary -->
> >                      <xsd:restriction base="xsd:string">
> >                                 <xsd:enumeration value="visible"/>
> >                                 <xsd:enumeration value="invisible"/>
> >                      </xsd:restriction>
> >             </xsd:simpleType>
> > 
> > 4.And, there are some mismatched or missed or redundant end tags.
> >          ex)       <xsd:element name="Host-info">  <!-- in 
> > "Conference-time" element -->
> >                                <xsd:complexType>
> >                                        <xsd:sequence>
> >                                                <xsd:element 
> > name="SIP-URI"  type="xsd:anyURI" use="required"/>
> >                                                 .......... 
> > (some elements)
> >                                         <xsd:sequence> <!-- 
> > you need to close the "sequence" with </xsd:sequence> -->
> >                                        <xsd:sequence>  <!-- 
> > and, you don't need one of the two "xsd:sequence" -->
> >                               <xsd:complexType>
> >                     </xsd:element>
> > 
> > [[Unvalid Schema Definition Errors]]
> > 
> > 5. You use [use="required"] severral times in definition of 
> > elements, which is not appropriate. minOccurs="1" can be 
> > used, instead.
> > 
> > 6. in your definition)      <xsd:element name="Security-mechanism">
> >                                        <xsd:complexType>
> >                                              <xsd:attribute 
> > value="TLS"  type="xsd:boolean" default="false"/>
> >                                              <xsd:attribute 
> > value="S-MIME"  type="xsd:boolean" default="false"/>
> >                                        </xsd:complexType>
> >                                   </xsd:element>
> > 
> >    I got an error indicating unappropriate use of "value" in 
> > attribute;
> >    I got the validation error in the following definition. I 
> > defined the type of Security-mechanism, and reuse it for the 
> > definition.
> >    Please let me know if it is different from your intention. 
> > Then, I'll correct it as your intention. 
> > 
> > 
> > 7.          <xsd:element name="Authorization-mechanism">
> >                <xsd:complexType>
> >                      <xsd:restriction base="xsd:string">
> >                           <xsd:enumeration value="Digest"/>
> >                           <xsd:enumeration value="None"/>
> >                      </xsd:restriction>
> >                      <xsd:attribute name="Password"  
> > type="xsd:string"/>
> >               </xsd:complexType>
> > 
> >      I got an error indicating wrong use of "restrction" 
> > based enumeration value in a complexType. 
> >      I tried to define the type of Authorixation-type for the 
> > enumeration values.
> > 
> > 
> > 8.           <xsd:element name="ACL">
> >                         <xsd:complexType>
> >                                  <xsd:sequence>
> >                                            <xsd:element 
> > name="ACL-target-URI" type="xsd:anyURI"  use="required" minOccurs="1" 
> >                                                
> > MaxOccurs="unbounded"/>  
> >                                                          
> > <xsd:complexType>
> >                                                               
> >      <xsd:attribute name="Access-type"  type="Access-mode"/>
> >                                                          
> > </xsd:complexType>
> >                                  </xsd:sequence>
> >                         </xsd:complexType>
> >                </xsd:element>
> > 
> >      Over the definition, the closed tag of "ACL-target-URI" 
> > element followed by MaxOccurs="unbounded" is not correct here, right? 
> >     I guess you'd like to make ACL-target-URI have an 
> > attribute, am I correct?
> >      Anyway, I got an error indicating unappropriate use of 
> > attribute here, so I changed "ACL" element to the form of  
> > "PCL" and "DL" in this moment, but it is not your intention, 
> > please let me know.
> > 
> > ------------------
> > 
> > I hope this will be helpful. 
> >    
> > Sincerely, 
> > Eunah
> > 
> > 
> > 
> > 
> > >
> > >
> > > ----- Original Message ----- 
> > > From: [email-masked] 
> > > To: [email-masked] ; [email-masked] 
> > > Cc: [email-masked] ; [email-masked] ; 
> > [email-masked] 
> > > Sent: Friday, June 27, 2003 10:51 PM
> > > Subject: RE: [XCON] Conference Policy Control 
> > > 
> > > 
> > > Hi Eunah,
> > > 
> > > Thanks for the input. CPCP is very different from floor 
> > control so we don't need to have same protocol
> > > for these (besides, XCAP is already used for presence-list 
> > manipulation which is similar to conf policy manipulation etc).
> > > 
> > > If you can provide input to CPCP (e.g. what parameters 
> > should be included in the policy, or finding errors in XML Schema) 
> > > that would be highly appreciated.  
> > > 
> > > Thanks,
> > > Petri
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: ext Eunsook Kim [mailto:[email-masked]]
> > >>Sent: 27 June, 2003 16:44
> > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> > >>Cc: [email-masked]; Isomaki Markus (NRC/Helsinki); JongHwa
> > >>Subject: Re: [XCON] Conference Policy Control 
> > >>
> > >>
> > >>Hisham,
> > >>
> > >>Thanks a lot for your response. 
> > >>
> > >>I've chosen SOAP for acessing server elements of conference 
> > policy control, because  it is a well-known standardized protocol. 
> > >>Besides, I believe there is a close relationship between 
> > conference policy and floor controls, and I think that it 
> > would be good for the two >>mechanisms to use the same protocol. 
> > >>As you know, Xioatao and Petri have already proposed a 
> > floor control draft using SOAP, 
> > >>so, I've prototyped a few basic functions of policy control 
> > using SOAP, and wrote my draft. 
> > >>However, SOAP is just one of the methods to allow client to 
> > access policy server information, and 
> > >>I'm willing to do it by using XCAP, too
> > >>
> > >>I think,  the main focus of this work is not if it should 
> > be SOAP or XCAP. 
> > >>In my opinion, it is more important to design well-formed 
> > schema for policy control operations which can be 
> > standardized, and I think the >>conference design team has 
> > been doing very good job in this point of view. And, as the 
> > one who is very interested in and working on this area, >>I'm 
> > very happy to hear the XCON bof announcement, and I'll be 
> > very happy if I can help or contribute some parts on the 
> > works of design team.
> > >>
> > >>I'll go over all the XCON drafts again, and I would like to 
> > discuss on this topic with you more in the mailing list, if 
> > you'd like to.
> > >>
> > >>I appreciate your response again.
> > >>
> > >>Yours faithfully, Eunah
> > >>
> > >>
> > >>
> > >>>----- Original Message ----- 
> > >>>From: [email-masked] 
> > >>>To: [email-masked] ; [email-masked] 
> > >>>Cc: [email-masked] ; [email-masked] 
> > >>>Sent: Friday, June 27, 2003 3:24 PM
> > >>>Subject: RE: [XCON] Conference Policy Control 
> > >>>
> > >>>
> > >>>Eunah,
> > >>>
> > >>>We appreciate your enthusiasm about the conferencing work.
> > >>>
> > >>>Your proposal so makes use of SOAP as a solution. To be 
> > honest, our interest in SOAP as a solution for conference 
> > policy protocol is very >>>minimal. That's why we chose XCAP, 
> > its simple and much lighter to implement than SOAP.
> > >>>
> > >>>If you feel that your proposal is the superior one, please 
> > feel free to involve yourself in the soon newly formed IETF 
> > working group, named >>>XCON, specifically designed to 
> > produce such conferencing protocols. The conferencing work so 
> > far has been done in a closed design team >>>where the XCAP 
> > has so far been well accepted as the conference policy solution.
> > >>>
> > >>>Much appreciated,
> > >>>Hisham
> > 
> > 
> > 
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Eunsook Kim" <[email-masked]>
To: [email-masked],  [email-masked]
Subject: Re: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00
Date: Tue, 1 Jul 2003 21:23:15 +0900
Organization: etri
Cc: [email-masked],  [email-masked]
Reply-To: Eunsook Kim <[email-masked]>
Sender: [email-masked]
This is a multi-part message in MIME format.

------=_NextPart_000_0116_01C34016.FBFD5E50
Content-Type: text/plain;
	charset="Windows-1252"
------=_NextPart_000_0116_01C34016.FBFD5E50
Content-Type: text/plain;
	charset="Windows-1252"
Content-Type: multipart/mixed;
 boundary="------------060505030705020100070604"
------=_NextPart_000_0116_01C34016.FBFD5E50
Content-Type: text/plain; charset="us-ascii"
Content-Type: multipart/mixed;
 boundary="------------060505030705020100070604"
MIME-Version: 1.0
Content-Disposition: inline

This is a multi-part message in MIME format.
--------------060505030705020100070604
Content-Type: 
Content-Transfer-Encoding: 8bit

Hi Petri, and Hisham

I went over XCAP and the related documents and admit that it gives simple and light method to manipulate conference policy. :-)
I also have looked over your document and the defined XML schema, and found a lot of syntax errors and several schema validation errors.
I tried to correct them, and attach the schema file, which I get the successful validation message by running it into the XMLSPY. 
Currently, I changed or added some of definition to get a valid schema. 
I tried to read your intention as possible as I can, but please let me know if the corrections doesn't carry well on your intention.
 
-----------------
The brief note of the errors is as following:

1. Namespace should be defined for 'conference-policy' in order to reuse types and elements defined in the document.

[[Syntax errors]]

2. Comment type should be <!--   --> instead <! >

3. There are many cases where definitions are unappropriately ended. I cannot list all of them here; give an example:
          <xsd:simpleType name="Visibility-type"/>   <!-- '/' not necessary -->
                     <xsd:restriction base="xsd:string">
                                <xsd:enumeration value="visible"/>
                                <xsd:enumeration value="invisible"/>
                     </xsd:restriction>
            </xsd:simpleType>

4.And, there are some mismatched or missed or redundant end tags.
         ex)       <xsd:element name="Host-info">  <!-- in "Conference-time" element -->
                               <xsd:complexType>
                                       <xsd:sequence>
                                               <xsd:element name="SIP-URI"  type="xsd:anyURI" use="required"/>
                                                .......... (some elements)
                                        <xsd:sequence> <!-- you need to close the "sequence" with </xsd:sequence> -->
                                       <xsd:sequence>  <!-- and, you don't need one of the two "xsd:sequence" -->
                              <xsd:complexType>
                    </xsd:element>

[[Unvalid Schema Definition Errors]]

5. You use [use="required"] severral times in definition of elements, which is not appropriate. minOccurs="1" can be used, instead.

6. in your definition)      <xsd:element name="Security-mechanism">
                                       <xsd:complexType>
                                             <xsd:attribute value="TLS"  type="xsd:boolean" default="false"/>
                                             <xsd:attribute value="S-MIME"  type="xsd:boolean" default="false"/>
                                       </xsd:complexType>
                                  </xsd:element>

   I got an error indicating unappropriate use of "value" in attribute;
   I got the validation error in the following definition. I defined the type of Security-mechanism, and reuse it for the definition.
   Please let me know if it is different from your intention. Then, I'll correct it as your intention. 

7.          <xsd:element name="Authorization-mechanism">
               <xsd:complexType>
                     <xsd:restriction base="xsd:string">
                          <xsd:enumeration value="Digest"/>
                          <xsd:enumeration value="None"/>
                     </xsd:restriction>
                     <xsd:attribute name="Password"  type="xsd:string"/>
              </xsd:complexType>

     I got an error indicating wrong use of "restrction" based enumeration value in a complexType. 
     I tried to define the type of Authorixation-type for the enumeration values.

8.           <xsd:element name="ACL">
                        <xsd:complexType>
                                 <xsd:sequence>
                                           <xsd:element name="ACL-target-URI" type="xsd:anyURI"  use="required" minOccurs="1" 
                                               MaxOccurs="unbounded"/>  
                                                         <xsd:complexType>
                                                                   <xsd:attribute name="Access-type"  type="Access-mode"/>
                                                         </xsd:complexType>
                                 </xsd:sequence>
                        </xsd:complexType>
               </xsd:element>

     Over the definition, the closed tag of "ACL-target-URI" element followed by MaxOccurs="unbounded" is not correct here, right? 
    I guess you'd like to make ACL-target-URI have an attribute, am I correct?
     Anyway, I got an error indicating unappropriate use of attribute here, so I changed "ACL" element to the form of  "PCL" and "DL" in this moment, but it is not your intention, please let me know.

------------------

I hope this will be helpful. 
   
Sincerely, 
Eunah

>
>
> ----- Original Message ----- 
> From: [email-masked] 
> To: [email-masked] ; [email-masked] 
> Cc: [email-masked] ; [email-masked] ; [email-masked] 
> Sent: Friday, June 27, 2003 10:51 PM
> Subject: RE: [XCON] Conference Policy Control 
> 
> 
> Hi Eunah,
> 
> Thanks for the input. CPCP is very different from floor control so we don't need to have same protocol
> for these (besides, XCAP is already used for presence-list manipulation which is similar to conf policy manipulation etc).
> 
> If you can provide input to CPCP (e.g. what parameters should be included in the policy, or finding errors in XML Schema) 
> that would be highly appreciated.  
> 
> Thanks,
> Petri
>
>
>
>>-----Original Message-----
>>From: ext Eunsook Kim [mailto:[email-masked]]
>>Sent: 27 June, 2003 16:44
>>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
>>Cc: [email-masked]; Isomaki Markus (NRC/Helsinki); JongHwa
>>Subject: Re: [XCON] Conference Policy Control 
>>
>>
>>Hisham,
>>
>>Thanks a lot for your response. 
>>
>>I've chosen SOAP for acessing server elements of conference policy control, because  it is a well-known standardized protocol. 
>>Besides, I believe there is a close relationship between conference policy and floor controls, and I think that it would be good for the two >>mechanisms to use the same protocol. 
>>As you know, Xioatao and Petri have already proposed a floor control draft using SOAP, 
>>so, I've prototyped a few basic functions of policy control using SOAP, and wrote my draft. 
>>However, SOAP is just one of the methods to allow client to access policy server information, and 
>>I'm willing to do it by using XCAP, too
>>
>>I think,  the main focus of this work is not if it should be SOAP or XCAP. 
>>In my opinion, it is more important to design well-formed schema for policy control operations which can be standardized, and I think the >>conference design team has been doing very good job in this point of view. And, as the one who is very interested in and working on this area, >>I'm very happy to hear the XCON bof announcement, and I'll be very happy if I can help or contribute some parts on the works of design team.
>>
>>I'll go over all the XCON drafts again, and I would like to discuss on this topic with you more in the mailing list, if you'd like to.
>>
>>I appreciate your response again.
>>
>>Yours faithfully, Eunah
>>
>>
>>
>>>----- Original Message ----- 
>>>From: [email-masked] 
>>>To: [email-masked] ; [email-masked] 
>>>Cc: [email-masked] ; [email-masked] 
>>>Sent: Friday, June 27, 2003 3:24 PM
>>>Subject: RE: [XCON] Conference Policy Control 
>>>
>>>
>>>Eunah,
>>>
>>>We appreciate your enthusiasm about the conferencing work.
>>>
>>>Your proposal so makes use of SOAP as a solution. To be honest, our interest in SOAP as a solution for conference policy protocol is very >>>minimal. That's why we chose XCAP, its simple and much lighter to implement than SOAP.
>>>
>>>If you feel that your proposal is the superior one, please feel free to involve yourself in the soon newly formed IETF working group, named >>>XCON, specifically designed to produce such conferencing protocols. The conferencing work so far has been done in a closed design team >>>where the XCAP has so far been well accepted as the conference policy solution.
>>>
>>>Much appreciated,
>>>Hisham

--------------060505030705020100070604
Content-Type: text/plain; charset=windows-1252;
 name="ATT26213.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ATT26213.txt"

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

--------------060505030705020100070604--