Subject: [XCON] 3GPP Requirements on CPCP

From: Markus.Isomaki at nokia.com ([email-masked])
Date: Wed Jul 16 13:26:27 2003

Hi,

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

Markus

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