- From: Keskar, Dhananjay V <dhananjay.v.keskar@intel.com>
- Date: Wed, 26 Jun 2002 18:20:06 -0700
- To: "'Butler, Mark'" <Mark_Butler@hplb.hpl.hp.com>, "'www-mobile@w3.org'" <www-mobile@w3.org>
Hi Mark, Those are valid questions, and thanks for the pointer to the SIP CC/PP draft. We envision rich client devices characterized by large profiles, with many - if not most - of the attributes being dynamic. Furthermore, these attributes would be changing values frequently. At the same time, a given server or applications on a server, may only be using a subset of these attributes in customization. Given this scenario, the current profile-diff scheme would send a large number of attribute values for every request to a given server, from which the server application may use only a few. Below are thoughts on possible mechanisms to make the attribute exchange more efficient. Some of these are easy and can be fit into the current exchange protocol. 1) Compressing the profile information sent out using CCPPEx. The exchange protocol notes that WBXML could be used for reducing the size. It is essential then to enable mandatory server-side support for compressed profiles. 2) Pre-negotiation (or negotiation as part of first request/response) between the client and the server on profiles/attributes used and desired by the server. The negotiation may be enabled through repositories in various ways. 1) The use of independent repositories, similar to that outlined in the SIP CC/PP draft. 1.a) Thus, the client can update repositories with changes to profile, and the server may only query for a subset of attributes. 1.b) Conversely, a repository may hold information about the CC/PP attributes used for customization in a given web space (server/path) which the client can query to decide which attribute values to send. 2) The client maintains its own repository of profiles, which the server can query before sending a response. Obviously, some of these solutions are much better than others. But the goal in writing this is to provide some ideas on our thinking. If you have any questions please let me know. Thanks dvk -----Original Message----- From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com] Sent: Monday, June 24, 2002 2:44 AM To: 'Keskar, Dhananjay V'; 'www-mobile@w3.org' Subject: RE: Issues and future work for CC/PP Hi dvk I have a few questions about your first issue - hope that's okay? > Our list of proposed work items is around the following issues: > 1. Consideration of Dynamic Properties > > Consideration of Dynamic Properties : > ============================ > Emerging high-end mobile devices distinguish themselves in > their ability to > adapt to changing computational requirements and > environmental conditions. > For example, power management policies adapt the speed of the > processor > based on remaining battery capacity, application workloads, > and quality of > service requirements. For network services to participate in > the adaptation, > the state of the client device must be communicated as > conditions change. In the current CC/PP protocol using HTTP-ex (or the WAP UAProf protocols) profile-diffs should be able to convey dynamic changes above and beyond the reference profile. Please can you give more details why profile-diffs are not suitable in the situations you describe? > Current implementations of CC/PP and the various transport > mechanisms do not > handle rapidly changing attributes efficiently. Thus mechanisms that > efficiently represent and convey dynamic properties in CC/PP > profiles need > to be considered. Can you give more details of these efficiency problems? Do you have any proposals for solutions? Alternatively do you think it would be possible to use a different protocol in your use case as outlined in http://alternic.net/drafts/drafts-n-o/draft-nishigaya-sip-ccpp-00.html ? thanks in advance, best regards Mark H. Butler, PhD Research Scientist HP Labs Bristol mark-h_butler@hp.com Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Wednesday, 26 June 2002 21:20:09 UTC