Subject: [XCON] 3GPP Requirements on CPCP

From: drage at lucent.com (Drage, Keith (Keith))
Date: Fri Jul 11 11:08:45 2003

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
>

---

From: jdrosen at dynamicsoft.com (Jonathan Rosenberg)
Date: Tue Jul 15 15:21:42 2003

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.

-- 
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