[XCON] Wireless Systems do not flee XML

[mfdolan at lucent.com (Dolan, Michael F (Mike))]

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:[e-mail]]
Sent: Thursday, July 24, 2003 5:08 PM
To: 'Dolan, Michael F (Mike)'; 'Michael Hammer'; 'Drage, Keith (Keith)'
Cc: [e-mail]
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
From adam at dynamicsoft.com  Tue Jul 29 15:05:23 2003
From: adam at dynamicsoft.com (Adam Roach)
Date: Tue Jul 29 14:05:34 2003
Subject: [XCON] Minutes, presentation online
Message-ID: <[e-mail]>

[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

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PQAMFBC5; Tue, 29 Jul 2003 15:12:48 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6TJAATh009689; Tue, 29 Jul 2003 15:10:12 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6TJ5XPo007845; Tue, 29 Jul 2003 14:05:35 -0500
Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6TJ5VPm007842 for <[e-mail]>; Tue, 29 Jul 2003 14:05:31 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6TJ5VSK009259 for <[e-mail]>; Tue, 29 Jul 2003 15:05:31 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <N4YYTQGX>; Tue, 29 Jul 2003 14:05:30 -0500
Message-ID: <[e-mail]>
From: Adam Roach <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 29 Jul 2003 14:05:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: [XCON] Minutes, presentation online
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

[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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PQAM14FB; Thu, 24 Jul 2003 18:28:41 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6OMPuXE008846; Thu, 24 Jul 2003 18:25:56 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OMRI2o000534; Thu, 24 Jul 2003 17:27:18 -0500
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OMGu2n000470 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Jul 2003 17:16:57 -0500
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6OMGqs14887; Thu, 24 Jul 2003 17:16:53 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id <PLZYJGH3>; Thu, 24 Jul 2003 17:16:52 -0500
Message-ID: <[e-mail]>
From: "Dolan, Michael F (Mike)" <[e-mail]>
To: Dean Willis <[e-mail]>,  "Dolan, Michael F (Mike)" <[e-mail]>, "'Michael Hammer'" <[e-mail]>,  "Drage, Keith (Keith)" <[e-mail]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 17:16:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset=windows-1252; format=flowed
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
Sent: Thursday, July 24, 2003 5:08 PM
To: 'Dolan, Michael F (Mike)'; 'Michael Hammer'; 'Drage, Keith (Keith)'
Cc: [e-mail]
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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PQAM14D5; Thu, 24 Jul 2003 18:13:54 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6OMB9XE008787; Thu, 24 Jul 2003 18:11:10 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OMCr2o000428; Thu, 24 Jul 2003 17:12:54 -0500
Received: from txdwillis (ds63-113-46-2.dynamicsoft.com [63.113.46.2]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OM8P2n000383 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 24 Jul 2003 17:08:30 -0500
From: "Dean Willis" <[e-mail]>
To: "'Dolan, Michael F \(Mike\)'" <[e-mail]>,  "'Michael Hammer'" <[e-mail]>, "'Drage, Keith \(Keith\)'" <[e-mail]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 17:08:17 -0500
Message-ID: <000901c35230$19d76440$022e713f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailman-Approved-At: Thu, 24 Jul 2003 17:12:52 -0500
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PQAM1T8T; Thu, 24 Jul 2003 17:01:40 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6OKwlXE008513; Thu, 24 Jul 2003 16:58:49 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OKxt2o032573; Thu, 24 Jul 2003 15:59:56 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OKxq2m032570 for <[e-mail]>; Thu, 24 Jul 2003 15:59:53 -0500
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6OKxnw08810 for <[e-mail]>; Thu, 24 Jul 2003 15:59:49 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id <PLZY208S>; Thu, 24 Jul 2003 15:59:48 -0500
Message-ID: <[e-mail]>
From: "Dolan, Michael F (Mike)" <[e-mail]>
To: Michael Hammer <[e-mail]>,  "Drage, Keith (Keith)" <[e-mail]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 15:59:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset=windows-1252; format=flowed
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
[e-mail]

-----Original Message-----
From: Michael Hammer [mailto:[e-mail]]
Sent: Thursday, July 24, 2003 12:48 PM
To: Drage, Keith (Keith)
Cc: [e-mail]; [e-mail]
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:[e-mail]]
> > Sent: 17 July 2003 18:44
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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, [e-mail] 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:[e-mail]]
> > >  > Sent: 16 July, 2003 22:10
> > >  > To: [e-mail]; [e-mail]
> > >  > Cc: [e-mail]; [e-mail]
> > >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > > -----Original Message-----
> > >  > > From: ext Rohan Mahy [mailto:[e-mail]]
> > >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> > >  > > To: Adam Roach
> > >  > > Cc: [e-mail]; [e-mail]
> > >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> > >  > >
> > >  > >
> > >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> > >  > >
> > >  > > > [e-mail] [mailto:[e-mail]] 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
> > >  > > > [e-mail]
> > >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  > > _______________________________________________
> > >  > > XCON mailing list
> > >  > > [e-mail]
> > >  > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  >
> > >  > _______________________________________________
> > >  > XCON mailing list
> > >  > [e-mail]
> > >  > http://www.softarmor.com/mailman/listinfo/xcon
> > >  >
> > >
> > >_______________________________________________
> > >XCON mailing list
> > >[e-mail]
> > >http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PQAM1TH7; Thu, 24 Jul 2003 13:49:38 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6OHknXE007502; Thu, 24 Jul 2003 13:46:51 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OHmC2o031612; Thu, 24 Jul 2003 12:48:14 -0500
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OHm92m031609 for <[e-mail]>; Thu, 24 Jul 2003 12:48:10 -0500
Received: from fruitpie.cisco.com (IDENT:[e-mail] [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6OHlepp015843; Thu, 24 Jul 2003 10:47:41 -0700 (PDT)
Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIF17742; Thu, 24 Jul 2003 10:47:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 24 Jul 2003 13:47:38 -0400
To: "Drage, Keith (Keith)" <[e-mail]>
From: Michael Hammer <[e-mail]>
Subject: RE: [XCON] Wireless Systems do not flee XML
In-Reply-To: <[e-mail] .lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
> > Sent: 17 July 2003 18:44
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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, [e-mail] 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:[e-mail]]
> > >  > Sent: 16 July, 2003 22:10
> > >  > To: [e-mail]; [e-mail]
> > >  > Cc: [e-mail]; [e-mail]
> > >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > > -----Original Message-----
> > >  > > From: ext Rohan Mahy [mailto:[e-mail]]
> > >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> > >  > > To: Adam Roach
> > >  > > Cc: [e-mail]; [e-mail]
> > >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> > >  > >
> > >  > >
> > >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> > >  > >
> > >  > > > [e-mail] [mailto:[e-mail]] 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
> > >  > > > [e-mail]
> > >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  > > _______________________________________________
> > >  > > XCON mailing list
> > >  > > [e-mail]
> > >  > > http://www.softarmor.com/mailman/listinfo/xcon
> > >  > >
> > >  >
> > >  > _______________________________________________
> > >  > XCON mailing list
> > >  > [e-mail]
> > >  > http://www.softarmor.com/mailman/listinfo/xcon
> > >  >
> > >
> > >_______________________________________________
> > >XCON mailing list
> > >[e-mail]
> > >http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PQAM1R0X; Thu, 24 Jul 2003 06:06:36 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6OA41DE006196; Thu, 24 Jul 2003 06:04:01 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OA5j2o029771; Thu, 24 Jul 2003 05:05:47 -0500
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6OA5g2m029768 for <[e-mail]>; Thu, 24 Jul 2003 05:05:43 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6OA5c529601 for <[e-mail]>; Thu, 24 Jul 2003 05:05:39 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id <PQ1DP33W>; Thu, 24 Jul 2003 11:05:38 +0100
Message-ID: <[e-mail]>
From: "Drage, Keith (Keith)" <[e-mail]>
To: "'Michael Hammer'" <[e-mail]>,  [e-mail]
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 24 Jul 2003 11:05:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=windows-1252; format=flowed
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
> Sent: 17 July 2003 18:44
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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, [e-mail] 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:[e-mail]]
> >  > Sent: 16 July, 2003 22:10
> >  > To: [e-mail]; [e-mail]
> >  > Cc: [e-mail]; [e-mail]
> >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> >  >
> >  >
> >  >
> >  >
> >  > > -----Original Message-----
> >  > > From: ext Rohan Mahy [mailto:[e-mail]]
> >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> >  > > To: Adam Roach
> >  > > Cc: [e-mail]; [e-mail]
> >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> >  > >
> >  > >
> >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> >  > >
> >  > > > [e-mail] [mailto:[e-mail]] 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
> >  > > > [e-mail]
> >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  > > _______________________________________________
> >  > > XCON mailing list
> >  > > [e-mail]
> >  > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  >
> >  > _______________________________________________
> >  > XCON mailing list
> >  > [e-mail]
> >  > http://www.softarmor.com/mailman/listinfo/xcon
> >  >
> >
> >_______________________________________________
> >XCON mailing list
> >[e-mail]
> >http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNSSCTTT; Tue, 22 Jul 2003 13:56:09 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MHrZMn002410; Tue, 22 Jul 2003 13:53:35 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MHse2o018619; Tue, 22 Jul 2003 12:54:41 -0500
Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MHsc2m018616 for <[e-mail]>; Tue, 22 Jul 2003 12:54:38 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MHsQiJ011609; Tue, 22 Jul 2003 13:54:26 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <N4YYTJ0J>; Tue, 22 Jul 2003 12:54:26 -0500
Message-ID: <[e-mail]>
From: Adam Roach <[e-mail]>
To: "'Kozdon, Peter'" <[e-mail]>,  [e-mail]
Subject: RE: [XCON] Charter
Date: Tue, 22 Jul 2003 12:54:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
> Sent: Wednesday, July 16, 2003 16:51
> To: [e-mail]
> 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNSSCTQY; Tue, 22 Jul 2003 13:31:09 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MHSZMn002244; Tue, 22 Jul 2003 13:28:35 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MHUS2o018534; Tue, 22 Jul 2003 12:30:28 -0500
Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MHUQ2m018531 for <[e-mail]>; Tue, 22 Jul 2003 12:30:26 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MHUQiJ011548 for <[e-mail]>; Tue, 22 Jul 2003 13:30:26 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <N4YYTJ9Y>; Tue, 22 Jul 2003 12:30:26 -0500
Message-ID: <[e-mail]>
From: Adam Roach <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 22 Jul 2003 12:30:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: [XCON] Reminder: IPR
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

[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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNSSCTQH; Tue, 22 Jul 2003 13:26:09 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MHNZMn002217; Tue, 22 Jul 2003 13:23:36 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MHOs2o018502; Tue, 22 Jul 2003 12:24:55 -0500
Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MHOq2m018499 for <[e-mail]>; Tue, 22 Jul 2003 12:24:52 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MHOaiJ011534; Tue, 22 Jul 2003 13:24:44 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <N4YYTJ94>; Tue, 22 Jul 2003 12:24:36 -0500
Message-ID: <[e-mail]>
From: Adam Roach <[e-mail]>
To: "'[e-mail]'" <[e-mail]>,  "'Bob Hughes'" <[e-mail]>, [e-mail]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Tue, 22 Jul 2003 12:24:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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

/a

> -----Original Message-----
> From: Victor A Paulsamy [mailto:[e-mail]]
> Sent: Thursday, July 17, 2003 13:20
> To: 'Bob Hughes'; [e-mail]
> Subject: RE: [XCON] Conference Controllers and Mixers
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNSSCTKF; Tue, 22 Jul 2003 12:42:18 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MGdX3o001605; Tue, 22 Jul 2003 12:39:34 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MGee2o018210; Tue, 22 Jul 2003 11:40:41 -0500
Received: from radvpost.radvision.com (radvmail.radvision.com [12.44.63.10]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MGeb2n018207 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 22 Jul 2003 11:40:38 -0500
Received: from radvpost.radvision.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Tue, 22 Jul 2003 12:39:03 -0400
Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id <P2YJY9XS>; Tue, 22 Jul 2003 12:39:03 -0400
Message-ID: <[e-mail]>
From: Orit Levin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 22 Jul 2003 12:38:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=windows-1252; format=flowed
Subject: [XCON] Floor Control: local m-line as a resource.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNSSCTG4; Tue, 22 Jul 2003 12:14:52 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MGC73o001470; Tue, 22 Jul 2003 12:12:07 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MGDc2o018086; Tue, 22 Jul 2003 11:13:39 -0500
Received: from radvpost.radvision.com (radvmail.radvision.com [12.44.63.10]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MGDa2n018083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 22 Jul 2003 11:13:37 -0500
Received: from radvpost.radvision.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Tue, 22 Jul 2003 12:12:03 -0400
Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id <P2YJY9W6>; Tue, 22 Jul 2003 12:12:03 -0400
Message-ID: <[e-mail]>
From: Orit Levin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 22 Jul 2003 12:12:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=windows-1252; format=flowed
Subject: [XCON] Floor Control: Its usage.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNSSCS0W; Tue, 22 Jul 2003 11:20:24 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6MFHmMn001338; Tue, 22 Jul 2003 11:17:48 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MFJH2o017819; Tue, 22 Jul 2003 10:19:19 -0500
Received: from radvpost.radvision.com (radvmail.radvision.com [12.44.63.10]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6MFJE2n017816 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 22 Jul 2003 10:19:16 -0500
Received: from radvpost.radvision.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Tue, 22 Jul 2003 11:17:40 -0400
Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id <P2YJY94T>; Tue, 22 Jul 2003 11:17:40 -0400
Message-ID: <[e-mail]>
From: Orit Levin <[e-mail]>
To: [e-mail]
Date: Tue, 22 Jul 2003 11:17:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=windows-1252; format=flowed
Subject: [XCON] Floor Control: Charter.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
> Sent: Thursday, July 17, 2003 5:12 AM
> To: Jonathan Rosenberg
> Cc: Rosen, Brian; [e-mail]
> 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 <[e-mail]>
> 17/07/2003 11:50 AM
> 
> To
> "Rosen, Brian" <[e-mail]>
> cc
> Avshalom Houri/Haifa/IBM@IBMIL, [e-mail]
> 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:[e-mail]]
> >>Sent: Thursday, July 17, 2003 4:04 AM
> >>To: [e-mail]
> >>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" <[e-mail]>
> >>Sent by: [e-mail]
> >>17/07/2003 12:50 AM
> >>
> >>To
> >>[e-mail]
> >>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
> >>[e-mail]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> >>_______________________________________________
> >>XCON mailing list
> >>[e-mail]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> >
> > _______________________________________________
> > XCON mailing list
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
> 
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLPA6GS0; Mon, 21 Jul 2003 17:32:28 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6LLTiUC002388; Mon, 21 Jul 2003 17:29:44 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6LLUt2o013500; Mon, 21 Jul 2003 16:30:56 -0500
Received: from mail26c.sbc-webhosting.com (mail26c.sbc-webhosting.com [216.173.237.166]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6LLUr2m013497 for <[e-mail]>; Mon, 21 Jul 2003 16:30:53 -0500
Received: from www.tamura-broad.com (64.143.38.143) by mail26c.sbc-webhosting.com (RS ver 1.0.83vs) with SMTP id 4-060683049; Mon, 21 Jul 2003 17:30:49 -0400 (EDT)
From: "Victor A Paulsamy" <[e-mail]>
To: "'Rosen, Brian'" <[e-mail]>,  "'Bob Hughes'" <[e-mail]>, [e-mail]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Mon, 21 Jul 2003 14:30:08 -0700
Organization: Tamura Corp
Message-ID: <000501c34fcf$42b52c20$4cfea8c0@victorpc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-Loop-Detect: 1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: [e-mail]
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]] 

>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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLPA6GNJ; Mon, 21 Jul 2003 16:41:05 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6LKcKUC002136; Mon, 21 Jul 2003 16:38:21 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6LKdZ2o013265; Mon, 21 Jul 2003 15:39:37 -0500
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6LKdV2m013262 for <[e-mail]>; Mon, 21 Jul 2003 15:39:34 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08601;  Mon, 21 Jul 2003 16:39:16 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26924;  Mon, 21 Jul 2003 16:38:28 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MXW29>; Mon, 21 Jul 2003 16:38:27 -0400
Message-ID: <[e-mail]>
From: "Rosen, Brian" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>,  "'Bob Hughes'" <[e-mail]>, [e-mail]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Mon, 21 Jul 2003 16:38:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
> Sent: Thursday, July 17, 2003 2:20 PM
> To: 'Bob Hughes'; [e-mail]
> Subject: RE: [XCON] Conference Controllers and Mixers
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQN5J; Thu, 17 Jul 2003 14:23:03 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6HIKSkG021379; Thu, 17 Jul 2003 14:20:29 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6HIL02o011813; Thu, 17 Jul 2003 13:21:00 -0500
Received: from mail26d.sbc-webhosting.com (mail26d.sbc-webhosting.com [216.173.237.167]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6HIKx2m011810 for <[e-mail]>; Thu, 17 Jul 2003 13:20:59 -0500
Received: from www.tamura-broad.com (64.143.38.143) by mail26d.sbc-webhosting.com (RS ver 1.0.83vs) with SMTP id 2-0542566042; Thu, 17 Jul 2003 14:20:43 -0400 (EDT)
From: "Victor A Paulsamy" <[e-mail]>
To: "'Bob Hughes'" <[e-mail]>,  [e-mail]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Thu, 17 Jul 2003 11:20:04 -0700
Organization: Tamura Corp
Message-ID: <000801c34c90$0bd5abe0$4cfea8c0@victorpc>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Loop-Detect: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6HIKx2m011810
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: [e-mail]
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQNZB; Thu, 17 Jul 2003 14:10:29 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6HI7skG021314; Thu, 17 Jul 2003 14:07:55 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6HI982o011740; Thu, 17 Jul 2003 13:09:09 -0500
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6HI932n011737 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Thu, 17 Jul 2003 13:09:06 -0500
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HI92J20971 for <[e-mail]>; Thu, 17 Jul 2003 21:09:03 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Thu, 17 Jul 2003 21:09:02 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Thu, 17 Jul 2003 21:09:02 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 17 Jul 2003 21:09:02 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Wireless Systems do not flee XML
Thread-Index: AcNMi4igXRUKKfzXT/m3hSn2uN6PgAAAc2HQ
From: [e-mail]
To: [e-mail],  [e-mail]
X-OriginalArrivalTime: 17 Jul 2003 18:09:02.0202 (UTC) FILETIME=[8088C5A0:01C34C8E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6HI932n011737
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: 17 July, 2003 20:44
> To: Niemi Aki (NMP/Helsinki)
> Cc: [e-mail]; [e-mail]
> 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, [e-mail] 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:[e-mail]]
> >  > Sent: 16 July, 2003 22:10
> >  > To: [e-mail]; [e-mail]
> >  > Cc: [e-mail]; [e-mail]
> >  > Subject: RE: [XCON] Wireless Systems do not flee XML
> >  >
> >  >
> >  >
> >  >
> >  > > -----Original Message-----
> >  > > From: ext Rohan Mahy [mailto:[e-mail]]
> >  > > Sent: Wednesday, July 16, 2003 3:53 PM
> >  > > To: Adam Roach
> >  > > Cc: [e-mail]; [e-mail]
> >  > > Subject: Re: [XCON] Wireless Systems do not flee XML
> >  > >
> >  > >
> >  > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> >  > >
> >  > > > [e-mail] [mailto:[e-mail]] 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
> >  > > > [e-mail]
> >  > > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  > > _______________________________________________
> >  > > XCON mailing list
> >  > > [e-mail]
> >  > > http://www.softarmor.com/mailman/listinfo/xcon
> >  > >
> >  >
> >  > _______________________________________________
> >  > XCON mailing list
> >  > [e-mail]
> >  > http://www.softarmor.com/mailman/listinfo/xcon
> >  >
> >
> >_______________________________________________
> >XCON mailing list
> >[e-mail]
> >http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQNWH; Thu, 17 Jul 2003 13:44:10 -0400
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6HHfO2D019121; Thu, 17 Jul 2003 13:41:25 -0400 (EDT)
Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2003 10:43:39 -0700
Received: from fruitpie.cisco.com (IDENT:[e-mail] [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6HHhruJ009483; Thu, 17 Jul 2003 10:43:54 -0700 (PDT)
Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHK11231; Thu, 17 Jul 2003 10:43:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 Jul 2003 13:43:52 -0400
To: [e-mail]
From: Michael Hammer <[e-mail]>
Subject: RE: [XCON] Wireless Systems do not flee XML
Cc: [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail]
In-Reply-To: <[e-mail] a.com>
Mime-Version: 1.0
--=====================_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, [e-mail] 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:[e-mail]]
 > Sent: 16 July, 2003 22:10
 > To: [e-mail]; [e-mail]
 > Cc: [e-mail]; [e-mail]
 > Subject: RE: [XCON] Wireless Systems do not flee XML
 > 
 > 
 > 
 > 
 > > -----Original Message-----
 > > From: ext Rohan Mahy [ mailto:[e-mail]]
 > > Sent: Wednesday, July 16, 2003 3:53 PM
 > > To: Adam Roach
 > > Cc: [e-mail]; [e-mail]
 > > Subject: Re: [XCON] Wireless Systems do not flee XML
 > > 
 > > 
 > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
 > > 
 > > > [e-mail] [ mailto:[e-mail]] 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
 > > > [e-mail]
 > > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > > _______________________________________________
 > > XCON mailing list
 > > [e-mail]
 > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > 
 > _______________________________________________
 > XCON mailing list
 > [e-mail]
 > http://www.softarmor.com/mailman/listinfo/xcon
 > 

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



X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQMM4; Thu, 17 Jul 2003 05:39:04 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H9aM2D017172; Thu, 17 Jul 2003 05:36:22 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H9bS2o009026; Thu, 17 Jul 2003 04:37:29 -0500
Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6H9bP2m009023 for <[e-mail]>; Thu, 17 Jul 2003 04:37:26 -0500
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap  id 20718; Thu, 17 Jul 2003 05:36:10 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Thu, 17 Jul 2003 05:37:25 -0400
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Conference Controllers and Mixers
Thread-Index: AcNMMx9vXZnGZ/QxTGC212e2EznYFgAEyruA
From: "Eric Burger" <[e-mail]>
To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6H9bP2m009023
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: Thu, July 17, 2003 3:11 AM
> To: 'Bob Hughes'; [e-mail]
> 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: [phone]
> Mobile: [phone]
> email: [e-mail]
> *************************************
> 
> -----Original Message-----
> From: Bob Hughes [mailto:[e-mail]]
> Sent: Wednesday, July 16, 2003 6:18 PM
> To: [e-mail]
> 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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQMK8; Thu, 17 Jul 2003 05:14:45 -0400
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H9C5kG018964; Thu, 17 Jul 2003 05:12:10 -0400 (EDT)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6H9EYJ21108; Thu, 17 Jul 2003 12:14:34 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Thu, 17 Jul 2003 12:14:33 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 12:14:32 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Thu, 17 Jul 2003 12:14:32 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Wireless Systems do not flee XML
Thread-Index: AcNLmVs/aJGZN/JjQ4mvknd4VHfZmQANGk6AAB0uGNA=
From: [e-mail]
To: [e-mail],  [e-mail],  [e-mail]
Cc: [e-mail],  [e-mail]
X-OriginalArrivalTime: 17 Jul 2003 09:14:32.0994 (UTC) FILETIME=[D5CBF820:01C34C43]

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:[e-mail]]
 > Sent: 16 July, 2003 22:10
 > To: [e-mail]; [e-mail]
 > Cc: [e-mail]; [e-mail]
 > Subject: RE: [XCON] Wireless Systems do not flee XML
 > 
 > 
 > 
 > 
 > > -----Original Message-----
 > > From: ext Rohan Mahy [mailto:[e-mail]]
 > > Sent: Wednesday, July 16, 2003 3:53 PM
 > > To: Adam Roach
 > > Cc: [e-mail]; [e-mail]
 > > Subject: Re: [XCON] Wireless Systems do not flee XML
 > > 
 > > 
 > > On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
 > > 
 > > > [e-mail] [mailto:[e-mail]] 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
 > > > [e-mail]
 > > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > > _______________________________________________
 > > XCON mailing list
 > > [e-mail]
 > > http://www.softarmor.com/mailman/listinfo/xcon
 > > 
 > 
 > _______________________________________________
 > XCON mailing list
 > [e-mail]
 > http://www.softarmor.com/mailman/listinfo/xcon
 > 


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQMK7; Thu, 17 Jul 2003 05:14:36 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H9Bp2D017088; Thu, 17 Jul 2003 05:11:54 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H9CX2o008835; Thu, 17 Jul 2003 04:12:34 -0500
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H9CR2m008832 for <[e-mail]>; Thu, 17 Jul 2003 04:12:28 -0500
Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6H9C4ZG037256; Thu, 17 Jul 2003 11:12:05 +0200
Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6H9BstC263000; Thu, 17 Jul 2003 11:11:55 +0200
In-Reply-To: <[e-mail]>
To: Jonathan Rosenberg <[e-mail]>
Subject: Re: [XCON] Charter
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: <[e-mail]>
From: "Avshalom Houri" <[e-mail]>
Date: Thu, 17 Jul 2003 12:11:47 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2003 12:11:54, Serialize complete at 17/07/2003 12:11:54
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
Cc: "Rosen, Brian" <[e-mail]>,  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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 <[e-mail]> 
17/07/2003 11:50 AM

To
"Rosen, Brian" <[e-mail]>
cc
Avshalom Houri/Haifa/IBM@IBMIL, [e-mail]
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:[e-mail]]
>>Sent: Thursday, July 17, 2003 4:04 AM
>>To: [e-mail]
>>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" <[e-mail]> 
>>Sent by: [e-mail]
>>17/07/2003 12:50 AM
>>
>>To
>>[e-mail]
>>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
>>[e-mail]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
>>_______________________________________________
>>XCON mailing list
>>[e-mail]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQMKL; Thu, 17 Jul 2003 05:08:53 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H96JkG018936; Thu, 17 Jul 2003 05:06:19 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H9852o008746; Thu, 17 Jul 2003 04:08:05 -0500
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H9802n008743 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 17 Jul 2003 04:08:01 -0500
Received: from magnum.cs.columbia.edu (IDENT:[e-mail] [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6H97qkM015173; Thu, 17 Jul 2003 05:07:52 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6H97og03303; Thu, 17 Jul 2003 05:07:51 -0400
Message-ID: <[e-mail]>
Date: Thu, 17 Jul 2003 05:03:41 -0400
From: Henning Schulzrinne <[e-mail]>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <[e-mail]>
Subject: Re: [XCON] Charter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQM29; Thu, 17 Jul 2003 04:51:34 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H8n0kG018874; Thu, 17 Jul 2003 04:49:00 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H8p02o008300; Thu, 17 Jul 2003 03:51:00 -0500
Received: from mail3.dynamicsoft.com ([63.113.44.69]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H8ow2m008297 for <[e-mail]>; Thu, 17 Jul 2003 03:50:59 -0500
Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H8oYiB011618;  Thu, 17 Jul 2003 04:50:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 17 Jul 2003 04:50:28 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <[e-mail]>
Subject: Re: [XCON] Charter
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
>>Sent: Thursday, July 17, 2003 4:04 AM
>>To: [e-mail]
>>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" <[e-mail]> 
>>Sent by: [e-mail]
>>17/07/2003 12:50 AM
>>
>>To
>>[e-mail]
>>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
>>[e-mail]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
>>_______________________________________________
>>XCON mailing list
>>[e-mail]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQM2N; Thu, 17 Jul 2003 04:44:39 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H8fv2D016959; Thu, 17 Jul 2003 04:41:57 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H8hw2o008257; Thu, 17 Jul 2003 03:43:59 -0500
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H8hu2m008254 for <[e-mail]>; Thu, 17 Jul 2003 03:43:56 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA27216;  Thu, 17 Jul 2003 04:43:55 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA11236;  Thu, 17 Jul 2003 04:43:55 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1M46L9>; Thu, 17 Jul 2003 04:43:55 -0400
Message-ID: <[e-mail]>
From: "Rosen, Brian" <[e-mail]>
To: "'Avshalom Houri'" <[e-mail]>,  [e-mail]
Subject: RE: [XCON] Charter
Date: Thu, 17 Jul 2003 04:43:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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:[e-mail]]
> Sent: Thursday, July 17, 2003 4:04 AM
> To: [e-mail]
> 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" <[e-mail]> 
> Sent by: [e-mail]
> 17/07/2003 12:50 AM
> 
> To
> [e-mail]
> 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQMGB; Thu, 17 Jul 2003 04:05:10 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H82akG018732; Thu, 17 Jul 2003 04:02:36 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H84Z2o008122; Thu, 17 Jul 2003 03:04:36 -0500
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H84W2m008119 for <[e-mail]>; Thu, 17 Jul 2003 03:04:33 -0500
Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6H84Po1020614 for <[e-mail]>; Thu, 17 Jul 2003 10:04:26 +0200
Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6H84BtC163098 for <[e-mail]>; Thu, 17 Jul 2003 10:04:12 +0200
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [XCON] Charter
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: <[e-mail]>
From: "Avshalom Houri" <[e-mail]>
Date: Thu, 17 Jul 2003 11:04:08 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/07/2003 11:04:11, Serialize complete at 17/07/2003 11:04:11
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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" <[e-mail]> 
Sent by: [e-mail]
17/07/2003 12:50 AM

To
[e-mail]
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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQMCV; Thu, 17 Jul 2003 03:11:28 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6H78rkG018549; Thu, 17 Jul 2003 03:08:54 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H7Al2o007839; Thu, 17 Jul 2003 02:10:48 -0500
Received: from accord-ntsrv3.polycom.co.il (212.199.61.2.forward.012.net.il [212.199.61.2]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6H7Ah2m007836 for <[e-mail]>; Thu, 17 Jul 2003 02:10:45 -0500
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id <31W6LGGG>; Thu, 17 Jul 2003 10:10:45 +0300
Message-ID: <C550397C3B6AEB418E62170D9E349CE21372D1@ACCORD-NTSRV3>
From: "Even, Roni" <[e-mail]>
To: "'Bob Hughes'" <[e-mail]>,  [e-mail]
Subject: RE: [XCON] Conference Controllers and Mixers
Date: Thu, 17 Jul 2003 10:10:43 +0300
X-Mailer: Internet Mail Service (5.5.2656.59)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-type: text/plain; charset=windows-1252; format=flowed
MIME-Version: 1.0
Content-transfer-encoding: 8bit

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: [phone]
Mobile: [phone]
email: [e-mail]
*************************************

-----Original Message-----
From: Bob Hughes [mailto:[e-mail]]
Sent: Wednesday, July 16, 2003 6:18 PM
To: [e-mail]
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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQLCK; Wed, 16 Jul 2003 17:56:02 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GLrJ2D015054; Wed, 16 Jul 2003 17:53:19 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GLsU2o006120; Wed, 16 Jul 2003 16:54:31 -0500
Received: from mail.siemenscom.com (mail.siemenscom.com [12.146.131.10]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GLsS2m006117 for <[e-mail]>; Wed, 16 Jul 2003 16:54:29 -0500
Received: from mail-stc.rolm.com (mail-stc.siemenscom.com [165.218.65.50]) by mail.siemenscom.com (8.9.3p2/8.9.3) with ESMTP id OAA23627 for <[e-mail]>; Wed, 16 Jul 2003 14:53:19 -0700 (PDT)
Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by mail-stc.rolm.com (8.11.6/8.11.6) with ESMTP id h6GLfCM11367 for <[e-mail]>; Wed, 16 Jul 2003 14:41:13 -0700 (PDT)
Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id <3TAKPYLG>; Wed, 16 Jul 2003 14:54:26 -0700
Message-ID: <[e-mail]>
From: "Kozdon, Peter" <[e-mail]>
To: [e-mail]
Subject: [XCON] Charter
Date: Wed, 16 Jul 2003 14:50:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=windows-1252; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

 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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQKNP; Wed, 16 Jul 2003 15:12:22 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GJ9mkG015947; Wed, 16 Jul 2003 15:09:49 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GJAM2o005432; Wed, 16 Jul 2003 14:10:23 -0500
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GJAK2m005421 for <[e-mail]>; Wed, 16 Jul 2003 14:10:20 -0500
Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <[e-mail]> for [e-mail]; Wed, 16 Jul 2003 19:08:13 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002)) with SMTP id <[e-mail]>; Wed, 16 Jul 2003 19:08:13 +0000 (GMT)
Received: from xs578v3521.mci.com ([166.50.113.41]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <[e-mail]>; Wed, 16 Jul 2003 19:07:20 +0000 (GMT)
Date: Wed, 16 Jul 2003 14:07:17 -0500
From: Alan Johnston <[e-mail]>
Subject: Re: [XCON] Comments on draft-ietf-sipping-cc-conferencing-01
In-reply-to: <[e-mail] e.com>
X-Sender: [e-mail]
To: Eric Burger <[e-mail]>,  "IETF XCON Discussion List (E-mail)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Content-type: text/plain; charset=us-ascii; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
>[e-mail]
>http://www.softarmor.com/mailman/listinfo/xcon

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQKNC; Wed, 16 Jul 2003 15:10:23 -0400
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GJ7f2D014242; Wed, 16 Jul 2003 15:07:41 -0400 (EDT)
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GJAHB05272; Wed, 16 Jul 2003 22:10:17 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Wed, 16 Jul 2003 22:10:17 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Jul 2003 22:10:17 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 22:10:17 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Wireless Systems do not flee XML
Thread-Index: AcNLmVs/aJGZN/JjQ4mvknd4VHfZmQANGk6A
From: [e-mail]
To: [e-mail],  [e-mail]
Cc: [e-mail],  [e-mail]
X-OriginalArrivalTime: 16 Jul 2003 19:10:17.0270 (UTC) FILETIME=[E4A1E560:01C34BCD]

> -----Original Message-----
> From: ext Rohan Mahy [mailto:[e-mail]]
> Sent: Wednesday, July 16, 2003 3:53 PM
> To: Adam Roach
> Cc: [e-mail]; [e-mail]
> Subject: Re: [XCON] Wireless Systems do not flee XML
> 
> 
> On Tuesday, July 15, 2003, at 11:56 PM, Adam Roach wrote:
> 
> > [e-mail] [mailto:[e-mail]] 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
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQKKQ; Wed, 16 Jul 2003 14:46:48 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GIiEkG015803; Wed, 16 Jul 2003 14:44:15 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GIjb2o005226; Wed, 16 Jul 2003 13:45:37 -0500
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GIjX2n005223 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 16 Jul 2003 13:45:35 -0500
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GIjWB18274 for <[e-mail]>; Wed, 16 Jul 2003 21:45:32 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Wed, 16 Jul 2003 21:45:32 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 16 Jul 2003 21:45:32 +0300
Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 16 Jul 2003 21:45:32 +0300
Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 16 Jul 2003 21:45:31 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] RE: Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 21:45:30 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] RE: Wireless Systems do not flee XML
Thread-Index: AcNLcxJN5dtu7OsdTouXpikKCuPLgQAOcIXAAAadduA=
From: [e-mail]
To: [e-mail],  [e-mail],  [e-mail],  [e-mail]
X-OriginalArrivalTime: 16 Jul 2003 18:45:31.0622 (UTC) FILETIME=[6F1E0060:01C34BCA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6GIjX2n005223
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: 16 July, 2003 18:24
> To: [e-mail]; Mayer Georg (NMP/Helsinki);
> [e-mail]
> 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:[e-mail]]
> > Sent: 16 July, 2003 11:12
> > To: Mayer Georg (NMP/Helsinki); [e-mail]
> > 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
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQKHP; Wed, 16 Jul 2003 14:27:53 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GIPJkG015643; Wed, 16 Jul 2003 14:25:19 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GIQQ2o005125; Wed, 16 Jul 2003 13:26:27 -0500
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GIQM2n005122 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 16 Jul 2003 13:26:25 -0500
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GIQLB03129 for <[e-mail]>; Wed, 16 Jul 2003 21:26:21 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Wed, 16 Jul 2003 21:26:21 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 16 Jul 2003 21:26:19 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Wed, 16 Jul 2003 21:26:19 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] 3GPP Requirements on CPCP
Thread-Index: AcNLD0Av8VDsg3x0Q/W42YT5D2ACxQAtxDLg
From: [e-mail]
To: [e-mail],  [e-mail]
X-OriginalArrivalTime: 16 Jul 2003 18:26:19.0841 (UTC) FILETIME=[C09A2B10:01C34BC7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6GIQM2n005122
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: 15 July, 2003 23:21
> To: Drage, Keith (Keith)
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> >>Sent: 10 July 2003 12:59
> >>To: [e-mail]
> >>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
> >>[e-mail]
> >>http://www.softarmor.com/mailman/listinfo/xcon
> >>
> > 
> > _______________________________________________
> > XCON mailing list
> > [e-mail]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQJPP; Wed, 16 Jul 2003 11:25:21 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GFMmkG014368; Wed, 16 Jul 2003 11:22:49 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GFNg2o004108; Wed, 16 Jul 2003 10:23:42 -0500
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GFNc2n004105 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 16 Jul 2003 10:23:41 -0500
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6GFNbB16393 for <[e-mail]>; Wed, 16 Jul 2003 18:23:37 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Wed, 16 Jul 2003 18:23:37 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 16 Jul 2003 18:23:36 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 16 Jul 2003 18:23:36 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] RE: Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 18:23:35 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] RE: Wireless Systems do not flee XML
Thread-Index: AcNLcxJN5dtu7OsdTouXpikKCuPLgQAOcIXA
From: [e-mail]
To: [e-mail],  [e-mail],  [e-mail]
X-OriginalArrivalTime: 16 Jul 2003 15:23:36.0438 (UTC) FILETIME=[39E7A160:01C34BAE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6GFNc2n004105
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: 16 July, 2003 11:12
> To: Mayer Georg (NMP/Helsinki); [e-mail]
> 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

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


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQJ3P; Wed, 16 Jul 2003 11:18:50 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GFGHkG014309; Wed, 16 Jul 2003 11:16:17 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GFIA2o004070; Wed, 16 Jul 2003 10:18:11 -0500
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6GFI72n004067 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 16 Jul 2003 10:18:08 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6GFI5Kb105600 for <[e-mail]>; Wed, 16 Jul 2003 11:18:05 -0400
Received: from d01ml072.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6GFI3GH039740 for <[e-mail]>; Wed, 16 Jul 2003 11:18:03 -0400
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <[e-mail]>
From: "Bob Hughes" <[e-mail]>
Date: Wed, 16 Jul 2003 11:18:01 -0400
X-MIMETrack: Serialize by Router on D01ML072/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 07/16/2003 11:18:03 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Subject: [XCON] Conference Controllers and Mixers
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQ20S; Wed, 16 Jul 2003 08:51:31 -0400
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6GCmm2D012158; Wed, 16 Jul 2003 08:48:49 -0400 (EDT)
Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2003 05:55:45 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6GCpIuD004038; Wed, 16 Jul 2003 05:51:18 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJF32531; Wed, 16 Jul 2003 05:48:17 -0700 (PDT)
Date: Wed, 16 Jul 2003 05:53:12 -0700
Subject: Re: [XCON] Wireless Systems do not flee XML
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0
Cc: [e-mail],  [e-mail],  [e-mail]
To: Adam Roach <[e-mail]>
From: Rohan Mahy <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Mailer: Apple Mail (2.552)

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

> [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQ2PZ; Wed, 16 Jul 2003 04:27:06 -0400
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6G8ON2D011386; Wed, 16 Jul 2003 04:24:23 -0400 (EDT)
Received: from magnum.cs.columbia.edu (IDENT:[e-mail] [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6G8QxkM011124; Wed, 16 Jul 2003 04:26:59 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6G8Qvg05017; Wed, 16 Jul 2003 04:26:57 -0400
Message-ID: <[e-mail]>
Date: Wed, 16 Jul 2003 04:22:48 -0400
From: Henning Schulzrinne <[e-mail]>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach <[e-mail]>
CC: [e-mail],  [e-mail],  [e-mail],  Xiaotao Wu <[e-mail]>
Subject: Re: [XCON] Wireless Systems do not flee XML
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

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.



X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQ2LB; Wed, 16 Jul 2003 03:05:38 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6G735kG012453; Wed, 16 Jul 2003 03:03:05 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6G75I26012633; Wed, 16 Jul 2003 02:05:18 -0500
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FLx124010392 for <[e-mail]>; Tue, 15 Jul 2003 16:59:02 -0500
Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6FLx0l7014840 for <[e-mail]>; Tue, 15 Jul 2003 16:59:01 -0500
Received: from fisherlatitude (unknown[135.210.8.44](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20030715215710gw100r9h89e>; Tue, 15 Jul 2003 21:57:10 +0000
From: "Steve Fisher" <[e-mail]>
To: "'Rohan Mahy'" <[e-mail]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Tue, 15 Jul 2003 17:58:21 -0400
Message-ID: <000f01c34b1c$353b92d0$2c08d287@fisherlatitude>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
X-Mailman-Approved-At: Wed, 16 Jul 2003 02:05:17 -0500
Cc: "'IETF XCON Discussion List \(E-mail\)'" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQ2KD; Wed, 16 Jul 2003 02:57:09 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6G6sQ2D011103; Wed, 16 Jul 2003 02:54:27 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6G6ue26012539; Wed, 16 Jul 2003 01:56:41 -0500
Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6G6ud24012533; Wed, 16 Jul 2003 01:56:39 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6G6uXE5011891; Wed, 16 Jul 2003 02:56:33 -0400 (EDT)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <N4YYTFHC>; Wed, 16 Jul 2003 01:56:33 -0500
Message-ID: <[e-mail]>
From: Adam Roach <[e-mail]>
To: [e-mail],  [e-mail],  [e-mail]
Subject: RE: [XCON] Wireless Systems do not flee XML
Date: Wed, 16 Jul 2003 01:56:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

[e-mail] [mailto:[e-mail]] 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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQG0B; Tue, 15 Jul 2003 16:23:05 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6FKKVkG010191; Tue, 15 Jul 2003 16:20:32 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FKLg26010018; Tue, 15 Jul 2003 15:21:43 -0500
Received: from mail3.dynamicsoft.com ([63.113.44.69]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FKLe24010013 for <[e-mail]>; Tue, 15 Jul 2003 15:21:40 -0500
Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6FKLXiB010400;  Tue, 15 Jul 2003 16:21:34 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 16:21:26 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <[e-mail]>
Subject: Re: [XCON] 3GPP Requirements on CPCP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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: [e-mail] [mailto:[e-mail]]
>>Sent: 10 July 2003 12:59
>>To: [e-mail]
>>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
>>[e-mail]
>>http://www.softarmor.com/mailman/listinfo/xcon
>>
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQF1L; Tue, 15 Jul 2003 07:44:32 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6FBfvkG007159; Tue, 15 Jul 2003 07:41:59 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FBhx26007427; Tue, 15 Jul 2003 06:44:00 -0500
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FBhw24007424 for <[e-mail]>; Tue, 15 Jul 2003 06:43:58 -0500
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6FBhkpp009976; Tue, 15 Jul 2003 04:43:46 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJD97094; Tue, 15 Jul 2003 04:40:54 -0700 (PDT)
Date: Tue, 15 Jul 2003 04:45:38 -0700
Subject: Re: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0
To: "Eric Burger" <[e-mail]>
From: Rohan Mahy <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Mailer: Apple Mail (2.552)
Cc: "IETF XCON Discussion List \(E-mail\)" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQF11; Tue, 15 Jul 2003 07:39:26 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6FBag2D006407; Tue, 15 Jul 2003 07:36:43 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FBcx26007397; Tue, 15 Jul 2003 06:39:00 -0500
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6FBcv24007394 for <[e-mail]>; Tue, 15 Jul 2003 06:38:58 -0500
Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 04:38:13 -0700
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6FBcouG011214; Tue, 15 Jul 2003 04:38:56 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJD96844; Tue, 15 Jul 2003 04:35:58 -0700 (PDT)
Date: Tue, 15 Jul 2003 04:40:42 -0700
Subject: Re: [XCON] Media Policy in Conferencing Framework
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0
To: "Eric Burger" <[e-mail]>
From: Rohan Mahy <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Mailer: Apple Mail (2.552)
Cc: "IETF XCON Discussion List \(E-mail\)" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQC81; Mon, 14 Jul 2003 14:46:56 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EIiLkG003407; Mon, 14 Jul 2003 14:44:23 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EIkM26003374; Mon, 14 Jul 2003 13:46:22 -0500
Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h6EIkL24003371 for <[e-mail]>; Mon, 14 Jul 2003 13:46:21 -0500
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap  id 1865; Mon, 14 Jul 2003 14:45:15 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
Date: Mon, 14 Jul 2003 14:46:20 -0400
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
Thread-Index: AcNKHUdzX4Yhbe2AQ/C2LCMiZ7MfdgAF7y2w
From: "Eric Burger" <[e-mail]>
To: "Michael Hammer" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6EIkL24003371
Cc: "IETF XCON Discussion List \(E-mail\)" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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

-----Original Message-----
From: Michael Hammer [mailto:[e-mail]]
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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQC5X; Mon, 14 Jul 2003 14:23:38 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EIKr2D002883; Mon, 14 Jul 2003 14:20:55 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EIMb26003277; Mon, 14 Jul 2003 13:22:38 -0500
Received: from accord-ntsrv3.polycom.co.il (212.199.61.2.forward.012.net.il [212.199.61.2]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EIMZ24003274 for <[e-mail]>; Mon, 14 Jul 2003 13:22:36 -0500
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id <31W6K5XR>; Mon, 14 Jul 2003 21:22:37 +0300
Message-ID: <C550397C3B6AEB418E62170D9E349CE21372A4@ACCORD-NTSRV3>
From: "Even, Roni" <[e-mail]>
To: "'Eric Burger'" <[e-mail]>,  "IETF XCON Discussion List (E-mail)" <[e-mail]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Mon, 14 Jul 2003 21:22:31 +0300
X-Mailer: Internet Mail Service (5.5.2656.59)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-type: text/plain; charset=windows-1252; format=flowed
MIME-Version: 1.0
Content-transfer-encoding: 8bit

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:[e-mail]]
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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQQCG4; Mon, 14 Jul 2003 11:33:47 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6EFVDkG002154; Mon, 14 Jul 2003 11:31:14 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EFXR26002628; Mon, 14 Jul 2003 10:33:27 -0500
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6EFXO24002625 for <[e-mail]>; Mon, 14 Jul 2003 10:33:24 -0500
Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Jul 2003 08:37:17 -0700
Received: from fruitpie.cisco.com (IDENT:[e-mail] [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6EFXMuD003370; Mon, 14 Jul 2003 08:33:22 -0700 (PDT)
Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHA07730; Mon, 14 Jul 2003 08:33:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Jul 2003 11:33:21 -0400
To: "Eric Burger" <[e-mail]>
From: Michael Hammer <[e-mail]>
Subject: Re: [XCON] Comments on draft-koskelainen-xcon-cpcp-reqs-00
In-Reply-To: <[e-mail] e.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
Cc: "IETF XCON Discussion List \(E-mail\)" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQP7B3; Fri, 11 Jul 2003 12:09:37 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6BG71IP024154; Fri, 11 Jul 2003 12:07:03 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6BG8j26006394; Fri, 11 Jul 2003 11:08:45 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6BG8g24006391 for <[e-mail]>; Fri, 11 Jul 2003 11:08:43 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6BG8cw07172 for <[e-mail]>; Fri, 11 Jul 2003 11:08:39 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id <3F6Z61RP>; Fri, 11 Jul 2003 17:08:37 +0100
Message-ID: <[e-mail]>
From: "Drage, Keith (Keith)" <[e-mail]>
To: [e-mail],  [e-mail]
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Fri, 11 Jul 2003 17:08:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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: [e-mail] [mailto:[e-mail]]
> Sent: 10 July 2003 12:59
> To: [e-mail]
> 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
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQP6FH; Fri, 11 Jul 2003 06:37:46 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6BAZEIP022581; Fri, 11 Jul 2003 06:35:14 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6BAbG26004797; Fri, 11 Jul 2003 05:37:17 -0500
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6BAbC25004794 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 11 Jul 2003 05:37:14 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6BAbAk19410 for <[e-mail]>; Fri, 11 Jul 2003 13:37:10 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Fri, 11 Jul 2003 13:37:10 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Fri, 11 Jul 2003 13:37:10 +0300
Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Fri, 11 Jul 2003 13:37:09 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Fri, 11 Jul 2003 13:37:08 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] 3GPP Requirements on CPCP
Thread-Index: AcNG62oKXYAv5lpgQqiKgtyKaogR0QAq7XMA
From: [e-mail]
To: [e-mail],  [e-mail]
X-OriginalArrivalTime: 11 Jul 2003 10:37:09.0516 (UTC) FILETIME=[61A2B4C0:01C34798]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h6BAbC25004794
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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:[e-mail]]
> Sent: 10 July, 2003 16:40
> To: Mayer Georg (NMP/Helsinki); [e-mail]
> 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, [e-mail] 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
> >[e-mail]
> >http://www.softarmor.com/mailman/listinfo/xcon
> 
> 

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQPYFV; Thu, 10 Jul 2003 09:59:21 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6ADue9F016709; Thu, 10 Jul 2003 09:56:40 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ADx126032172; Thu, 10 Jul 2003 08:59:01 -0500
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ADwx24032169 for <[e-mail]>; Thu, 10 Jul 2003 08:58:59 -0500
Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <[e-mail]> for [e-mail]; Thu, 10 Jul 2003 13:55:06 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002)) with SMTP id <[e-mail]>; Thu, 10 Jul 2003 13:55:06 +0000 (GMT)
Received: from xs578v3521.mci.com ([166.50.104.1]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <[e-mail]>; Thu, 10 Jul 2003 13:54:17 +0000 (GMT)
Date: Thu, 10 Jul 2003 08:40:12 -0500
From: Alan Johnston <[e-mail]>
Subject: Re: [XCON] 3GPP Requirements on CPCP
In-reply-to: <[e-mail] a.com>
X-Sender: [e-mail]
To: [e-mail],  [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Content-type: text/plain; charset=us-ascii; format=flowed
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

Hi Georg,

Thanks for your comments.  See mine below.

Thanks,
Alan Johnston
MCI

At 02:58 PM 7/10/2003 +0300, [e-mail] 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
>[e-mail]
>http://www.softarmor.com/mailman/listinfo/xcon

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQPY1L; Thu, 10 Jul 2003 09:47:29 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6ADivIP017795; Thu, 10 Jul 2003 09:44:58 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ADl226032114; Thu, 10 Jul 2003 08:47:02 -0500
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ADl024032111 for <[e-mail]>; Thu, 10 Jul 2003 08:47:00 -0500
Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <[e-mail]> for [e-mail]; Thu, 10 Jul 2003 13:42:56 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002)) with SMTP id <[e-mail]>; Thu, 10 Jul 2003 13:42:56 +0000 (GMT)
Received: from xs578v3521.mci.com ([166.50.104.1]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <[e-mail]>; Thu, 10 Jul 2003 13:42:55 +0000 (GMT)
Date: Thu, 10 Jul 2003 08:42:55 -0500
From: Alan Johnston <[e-mail]>
Subject: Re: [XCON] 3GPP Requirements on CPCP
In-reply-to: <OF8A2B8979.7E22023D-ON85256D5F.00426C46@LocalDomain>
X-Sender: [e-mail]
To: [e-mail],  [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Content-type: text/plain; charset=us-ascii; format=flowed
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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, [e-mail] 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
>[e-mail]
>http://www.softarmor.com/mailman/listinfo/xcon

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


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQPYB3; Thu, 10 Jul 2003 09:17:37 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6ADEt9F016524; Thu, 10 Jul 2003 09:14:56 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ADHG26032010; Thu, 10 Jul 2003 08:17:16 -0500
Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ACC225031665 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Jul 2003 07:12:03 -0500
Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6ACBuBr010618; Thu, 10 Jul 2003 08:11:57 -0400 (EDT)
Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6ACBojK009560; Thu, 10 Jul 2003 08:11:51 -0400 (EDT)
To: [e-mail]
Subject: Re: [XCON] 3GPP Requirements on CPCP
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8A2B8979.7E22023D-ON85256D5F.00426C46@LocalDomain>
From: [e-mail]
Date: Thu, 10 Jul 2003 08:11:47 -0400
X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12  |February 13, 2003) at 07/10/2003 08:09:53 AM, Serialize complete at 07/10/2003 08:09:53 AM
X-Mailman-Approved-At: Thu, 10 Jul 2003 08:17:11 -0500
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-transfer-encoding: 8bit

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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3QXQPX8S; Thu, 10 Jul 2003 08:20:49 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6ACI89F016341; Thu, 10 Jul 2003 08:18:08 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ACKV26031708; Thu, 10 Jul 2003 07:20:31 -0500
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6ACKQ25031704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL);  Thu, 10 Jul 2003 07:20:28 -0500
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6ACKPa18805; Thu, 10 Jul 2003 15:20:25 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Thu, 10 Jul 2003 15:20:21 +0300
Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Thu, 10 Jul 2003 15:20:20 +0300
Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Thu, 10 Jul 2003 15:20:20 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [XCON] 3GPP Requirements on CPCP
Date: Thu, 10 Jul 2003 15:20:18 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] 3GPP Requirements on CPCP
Thread-Index: AcNG3HjGrhG/6dfTQAefI68JaylCTgAAL8oA
From: [e-mail]
To: [e-mail]
X-OriginalArrivalTime: 10 Jul 2003 12:20:20.0138 (UTC) FILETIME=[A11EE8A0:01C346DD]
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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 [e-mail] [mailto:[e-mail]]
Sent: 10 July, 2003 15:12
To: Mayer Georg (NMP/Helsinki)
Cc: [e-mail]; [e-mail]
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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWGGLD9Q; Wed, 2 Jul 2003 02:48:14 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h626jgcF010964; Wed, 2 Jul 2003 02:45:43 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h626ln25004965; Wed, 2 Jul 2003 01:47:50 -0500
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h626li25004962 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Wed, 2 Jul 2003 01:47:47 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h626lh926947 for <[e-mail]>; Wed, 2 Jul 2003 09:47:43 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>;  Wed, 2 Jul 2003 09:47:42 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);  Wed, 2 Jul 2003 09:47:42 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1252; format=flowed
Subject: RE: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00
Date: Wed, 2 Jul 2003 09:47:39 +0300
Message-ID: <[e-mail]>
Thread-Topic: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00
Thread-Index: AcNAXuG1e1HoT6HeSVWeOsnQxroXCQABbB+Q
From: [e-mail]
To: [e-mail],  [e-mail]
X-OriginalArrivalTime: 02 Jul 2003 06:47:42.0878 (UTC) FILETIME=[D65CB3E0:01C34065]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h626li25004962
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

> -----Original Message-----
> From: ext Eunsook Kim [mailto:[e-mail]]
> Sent: Wednesday, July 02, 2003 8:57 AM
> To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> Cc: [e-mail]; Isomaki Markus (NRC/Helsinki);
> [e-mail]; [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>; <[e-mail]>
> 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:[e-mail]]
> > > Sent: Tuesday, July 01, 2003 3:23 PM
> > > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham 
> (NMP/Helsinki)
> > > Cc: [e-mail]; Isomaki Markus (NRC/Helsinki);
> > > [e-mail]; [e-mail]
> > > 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: [e-mail] 
> > > > To: [e-mail] ; [e-mail] 
> > > > Cc: [e-mail] ; [e-mail] ; 
> > > [e-mail] 
> > > > 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:[e-mail]]
> > > >>Sent: 27 June, 2003 16:44
> > > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri 
> (NRC/Tampere)
> > > >>Cc: [e-mail]; 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: [e-mail] 
> > > >>>To: [e-mail] ; [e-mail] 
> > > >>>Cc: [e-mail] ; [e-mail] 
> > > >>>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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWGGLD71; Wed, 2 Jul 2003 01:58:06 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h625tQXm009824; Wed, 2 Jul 2003 01:55:27 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h625vS25004817; Wed, 2 Jul 2003 00:57:29 -0500
Received: from cms3.cms.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h625vQ24004814 for <[e-mail]>; Wed, 2 Jul 2003 00:57:27 -0500
Received: from eunahdesktop (eunah.etri.re.kr [129.254.112.200]) by cms3.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3D4K7TYD; Wed, 2 Jul 2003 14:57:28 +0900
Message-ID: <009e01c3405e$d0606e70$c870fe81@eunahdesktop>
From: "Eunsook Kim" <[e-mail]>
To: [e-mail],  [e-mail]
References: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1252; format=flowed
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by bdsl.greycouncil.com id h625vQ24004814
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: Eunsook Kim <[e-mail]>
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
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:[e-mail]]
> > Sent: Tuesday, July 01, 2003 3:23 PM
> > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham (NMP/Helsinki)
> > Cc: [e-mail]; Isomaki Markus (NRC/Helsinki);
> > [e-mail]; [e-mail]
> > 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: [e-mail] 
> > > To: [e-mail] ; [e-mail] 
> > > Cc: [e-mail] ; [e-mail] ; 
> > [e-mail] 
> > > 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:[e-mail]]
> > >>Sent: 27 June, 2003 16:44
> > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> > >>Cc: [e-mail]; 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: [e-mail] 
> > >>>To: [e-mail] ; [e-mail] 
> > >>>Cc: [e-mail] ; [e-mail] 
> > >>>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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon


X-Mozilla-Status: 0011
X-Mozilla-Status2: 10000000
Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWGGLCPL; Tue, 1 Jul 2003 14:37:21 -0400
Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h61IYGYA007598; Tue, 1 Jul 2003 14:34:43 -0400 (EDT)
Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h61DiF25031052; Tue, 1 Jul 2003 08:44:15 -0500
Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h61CNT24028759 for <[e-mail]>; Tue, 1 Jul 2003 07:23:30 -0500
Received: from eunahdesktop (eunah.etri.re.kr [129.254.112.200]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h61CaQ911274; Tue, 1 Jul 2003 21:36:27 +0900 (KST)
Message-ID: <011801c33fcb$8cd47270$c870fe81@eunahdesktop>
From: "Eunsook Kim" <[e-mail]>
To: [e-mail],  [e-mail]
References: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------060505030705020100070604"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailman-Approved-At: Tue, 01 Jul 2003 08:44:14 -0500
X-Content-Filtered-By: Mailman/MimeDel 2.1.2
Cc: [e-mail],  [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: Eunsook Kim <[e-mail]>
List-Id: IETF XCON BOF  <xcon.softarmor.com>
List-Unsubscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.softarmor.com/pipermail/xcon>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.softarmor.com/mailman/listinfo/xcon>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
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: [e-mail] 
> To: [e-mail] ; [e-mail] 
> Cc: [e-mail] ; [e-mail] ; [e-mail] 
> 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:[e-mail]]
>>Sent: 27 June, 2003 16:44
>>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
>>Cc: [e-mail]; 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: [e-mail] 
>>>To: [e-mail] ; [e-mail] 
>>>Cc: [e-mail] ; [e-mail] 
>>>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
[e-mail]
http://www.softarmor.com/mailman/listinfo/xcon

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