RE: [XCON] CPCP requirements to support IMS

["Drage, Keith (Keith)" <[e-mail]>]

While I agree it is fairly urgent to get a decision made on the protocol, you started this thread with a call for checking and possibly enhancing the requirements.

If we are not going to wait for the requirements to be complete before making a decision on the protocol, then there is not point in having a requirements phase.

I submit that we should only make a decision when we have some agreement that the requirements are reasonably stable. The only decision I saw stepping this direction at the last IETF meeting was that the requirements draft should become a WG item.

regards

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 24 November 2003 13:14
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: [XCON] CPCP requirements to support IMS
> 
> 
> Hello Keith et al,
> 
> > At this moment in time it is premature to make any decisions 
> > about protocol, but I would certainly believe that we retain 
> > the flexibility to choose a different protocol for each of 
> > the above, based on different underlying requirements. If we 
> > choose the same protocol for membership policy as for 
> > resource list management in presence, then it will be because 
> > the requirements are similar.
> 
> well, I would say that one of the requirements from a 
> wireless SIP device (regardless whether it makes use of IMS 
> or not) is for sure to have a small set of protocols that it 
> needs to faciliate to be able to make use of SIP services.
> 
> Furthermore I would like to see common solutions for similar 
> requirements and CPCP looks very similar to the presence 
> related data manipulation to me. Now from the IMS perspective 
> it would be very valuable to have only one protocol for such 
> issues here. We also did not chose a different messaging or 
> presence protocol in IMS, we used SIP for this - so I hope we 
> can have the same for the so-called "data manipulation" issues.
> 
> Means: As long as there is not good other reasons (such as 
> Peter pointed out e.g. for floor control), I see good 
> arguments for applying XCAP for CPCP. I think I am not the 
> only one who agrees on that.
> 
> Besides that I see that we really need to decide on a 
> protocol for CPCP and cannot allow ourselves to wait longer. 
> So this is in no way premature. 
> 
> I do not understand how you can say it is premature. Your 
> argumentation in CN1 is, that IETF solutionw are not mature 
> enough, so that 3G cannot officially (in a TS) state that 
> something is taken from IETF. So let's go for IETF solutions 
> and make them mature even in your eyes. 
> 
> Best regards
> Georg
> 
> > -----Original Message-----
> > From: ext Drage, Keith (Keith) [mailto:[e-mail]]
> > Sent: 21 November, 2003 18:55
> > To: Khartabil Hisham (NMP-MSW/Helsinki); [e-mail];
> > [e-mail]
> > Cc: Mayer Georg (NMP-MSW/Helsinki)
> > Subject: RE: [XCON] CPCP requirements to support IMS
> > 
> > 
> > Which functionality is floor control policy.
> > 
> > As far as I understand the conferencing framework document, we have
> > 
> > -	conference control policy protocol, which in itself is 
> > divided into:
> > 	-	membership policy
> > 	-	media policy
> > 
> > and
> > -	floor control
> > 
> > I have not seen any mention of floor control policy. I 
> > believe requirements concerning creation and removal of 
> > floors are now considered to be CPCP, but I am not sure where 
> > they fall in the above divisions.
> > 
> > The floor control requirements already contain REQ-15	
> > "Bandwidth and terminal limitations SHOULD be taken into 
> > account in order to ensure that floor control can be 
> > efficiently used in mobile environments."
> > 
> > In order to meet the very immediate response needs of floor 
> > control, for 3GPP2 I would understand that floor control 
> > really needs to sit in their short data bursts, which has a 
> > limit of something like 50 octets. When I give the floor to 
> > someone, I certainly want them to be able to start speaking 
> > almost immediately. When I take the floor away from someone, 
> > I absolutely do not want them to continue for another 10 
> > sentences (assuming they were speaking in sentences in the 
> > first place!!!!).
> > 
> > At this moment in time it is premature to make any decisions 
> > about protocol, but I would certainly believe that we retain 
> > the flexibility to choose a different protocol for each of 
> > the above, based on different underlying requirements. If we 
> > choose the same protocol for membership policy as for 
> > resource list management in presence, then it will be because 
> > the requirements are similar.
> > 
> > regards
> > 
> > Keith
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]]
> > > Sent: 20 November 2003 14:59
> > > To: [e-mail]; [e-mail]
> > > Cc: [e-mail]
> > > Subject: RE: [XCON] CPCP requirements to support IMS
> > > 
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]]On 
> > > Behalf Of ext
> > > > Leis Peter
> > > > Sent: 20.November.2003 13:43
> > > > To: [e-mail]
> > > > Cc: Mayer Georg (NMP-MSW/Helsinki)
> > > > Subject: AW: [XCON] CPCP requirements to support IMS
> > > > 
> > > > 
> > > > hi Georg,
> > > > 
> > > > I think XCAP is not the right decission for floor control. 
> > > > Floor control certainly has some real time requirements while 
> > > > XCAP is a protocol for data administration. In addition the 
> > > > decission to use XCAP (over Ut interface) for floor control 
> > > > is not yet made within 3GPP. 
> > > 
> > > I agree, but I think floor control is different that floor 
> > > control policy.
> > > 
> > > > 
> > > > Another issue is compression. As far as I know there is no 
> > > > procedure for compression of XCAP (at least up till now). But 
> > > > for floor control which might happen quite frequently during 
> > > > an active conference we need a protocol that can be compressed.
> > > 
> > > That's a HTTP issue. You can compress HTTP. I'm not sure if 
> > > there already exists a HTTP dictionary. We might also need a 
> > > dictionary for the XML document carried in HTTP (XCAP). But 
> > > is this issue so important in the first phase of this work 
> > > that a requirement is needed that state that the protocol 
> > > must be compressible (if such work exists:)?
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > > 
> > > > 
> > > > Peter
> > > > 
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: [e-mail] [mailto:[e-mail]]
> > > > Gesendet: Donnerstag, 20. November 2003 10:51
> > > > An: [e-mail]
> > > > Betreff: [XCON] CPCP requirements to support IMS
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > as the CPCP issue is one very crucial for 3GPP, I would like 
> > > > to summarize some requirements from the IMS side. Please be 
> > > > aware that these are not official 3G requirements, but are my 
> > > > personal summary. I am the rapporteur of the technical 
> > > > specifications for IMS Conferencing protocol (stage 3) and 
> > > > collected some of the issues raised during the last meetings.
> > > > 
> > > > The time frame for finishing IMS conferencing in 3GPP are 
> > > > quite tight again. SIP related stuff for Conferencing is 
> > > > mostly done in the IMS spec, but for CPCP there is a complete 
> > > > lack and we are desperately looking for progress. The below 
> > > > issues should be decided on until latest mid of February, so 
> > > > that we have a chance to go on with conferencing in IMS.
> > > > 
> > > > Here we go:
> > > > 
> > > > - creation of a conference URI as well as of a 
> > > conference-factory URI
> > > > 
> > > > Well that's so basic - I do not want to go through all the 
> > > > requirements which are already there 
> > > > 
> > > > 
> > > > - indication that user is automatically unsubscribed from 
> > > > conference event subscription when user is leaving
> > > > 
> > > > This saves a lot of bandwidht on the air interface, as the 
> > > > user will just receive a NOTIFY with a Subscription-State 
> > > > header set to "terminated" that additionally indicates that 
> > > > it has left the conference (two SIP messages) instead of 
> > > > receiving the notification about his/her own leaving, sending 
> > > > a un-SUBSCRIBE, receiving another NOTIFY (6 messages). 
> > > > 
> > > > 
> > > > 
> > > > - Dial-Out lists which state that the focus should either 
> > > > send INVITE or REFER to the invited user. 
> > > > 
> > > > Both options (INVITE and REFER) are needed in order to allow 
> > > > different charging models. 
> > > > 
> > > > It is not feasable that e.g. the moderator sends the REFER 
> > > > requests to the invited users, as this will put high load to 
> > > > the air interface (REFER + 2 NOTIFYs = 6 messages per 
> > > REFERED-to user)
> > > > 
> > > > 
> > > > 
> > > > - CPCP solution must be based on XCAP
> > > > 
> > > > The interface for Data Manipulation in 3GPP IMS is the Ut 
> > > > interface. Over that the following issues will be handled:
> > > > 	- Presence related data manipulation
> > > > 	- CPCP 
> > > > 	- Floor Control
> > > > 	- generic data manipulation
> > > > 
> > > > In order to have one common interface, that could also be 
> > > > handled by the UE (and the related service applications in 
> > > > the network) in a common way, it is highly required that all 
> > > > these issues are solved by one protocol. 
> > > > 
> > > > This would also gurantee common security, charging, etc. 
> > > > models for the Ut interface.
> > > > 
> > > > 
> > > > Please ask if you need information on the IMS related issues. 
> > > > 
> > > > Thanks and best regards
> > > > Georg
> > > > 
> > > > _______________________________________________
> > > > XCON mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > > 
> > > > _______________________________________________
> > > > XCON mailing list
> > > > [e-mail]
> > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > > 
> > > 
> > > _______________________________________________
> > > XCON mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > 
> 

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