- From: Johan Hjelm <johan.hjelm@era-t.ericsson.se>
- Date: Thu, 22 Nov 2001 08:41:39 +0900
- To: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
- CC: "'Suryanarayana, Lalitha'" <lalitha@tri.sbc.com>, www-mobile@w3.org
- Message-ID: <3BFC3BB3.D3CB3938@era-t.ericsson.se>
Keio University proved that the profile caching made the data transfer considerably more efficient in their SASA implementation, in the paper presented at MDM'01. Johan "Butler, Mark" wrote: > Lalitha > > Firstly I regard these as implementation issues rather than issues that > require changes to the specification as they are primarily concerned with > efficiency. > > My concern is although it is legal for requests to omit profile references, > if they do then the origin server cannot cache profiles, reducing the > efficiency of the origin server. Note when I say caching I mean the > reference profile, not the profile diff. If servers cache the reference > profile, they can still cope with turning the sound off or changing location > as you describe. Caching by the origin server is not mandated by the > standard but currently I think it is one way of improving efficiency - see > my implementation for more details. If someone can explain why it is a bad > idea or a better approach then let me know - comments or criticisms on my > implementation are very welcome. > > If caching is done at the gateway this also reduces load on the profile > repository. However as Nick points out this dramatically increases the size > of HTTP request headers, which could adversely effect network performance, > and the gateway supplier has to support this as it's not mandated by the > standard. > > Also, just to confirm, I've tested DELI and it can cope with requests that > omit profile references - see the test plan distributed with the source code > for more details. > > best regards > > Mark Butler > Research Scientist > HP Labs Bristol > > -----Original Message----- > From: Suryanarayana, Lalitha [mailto:lalitha@tri.sbc.com] > Sent: 21 November 2001 16:00 > To: 'Butler, Mark' > Cc: www-mobile@w3.org > Subject: RE: CC/PP profile repository overworked? > > Mark: > > I do not think I understand your concern. The original intent was to be able > to support the ability to send the profile on every request although the > expectation was that implementors would use the caching mechanisms etc. The > rationale was the potential likelihood of changes to the profile CPI in > between 2 requests (eg location or someone turning sound on or off, etc). > > The headers look fine to me. > > When in doubt I would look at http://www.w3.org/TR/NOTE-CCPPexchange as a > basis, even for the x-wap-profile and x-wap-profile-diff headers. > > Regarding your other note on RDF on the UAProf mailing list, I noted that > Johan has forwarded it to the W3C group, which is the right place for the > issue to be discussed. > > Lalitha > > -----Original Message----- > From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com] > Sent: Tuesday, November 20, 2001 9:08 AM > To: 'eizdepski@cysive.com'; nick.denny@mci.co.uk > Cc: www-mobile@w3.org > Subject: RE: CC/PP profile repository overworked? > > Erich's absolutely right - reading the UAProf specs, section 9.1.1.1 page 38 > > "The x-wap-profile header is a general header field which must contain the > following: > - a URI referencing the CPI or > - a reference to a profile difference, transported using the > x-wap-profile-diff or > - a combination of multiple instances of these two types of data." > > This means headers of the following form are legal: > > GET /ccpp/html/ HTTP/1.1 > Host: localhost > x-wap-profile:"1-Rb0sq/nuUFQU75vAjKyiHw==" > x-wap-profile-diff:1;<?xml version="1.0"?> > <rdf:RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#"> > <rdf:Description rdf:ID="MyDeviceProfile"> > <prf:component> > <rdf:Description rdf:ID="HardwarePlatform"> > <rdf:type > rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema- > 20010426#HardwarePlatform"/> > <prf:BitsPerPixel>16</prf:BitsPerPixel> > </rdf:Description> > </prf:component> > </rdf:Description> > </rdf:RDF> > > I hadn't realised this - I expect DELI will not parse such requests as it > expects a profile reference. I'll note it as an issue to be fixed in the > next release. > > However I think this is an inefficient way of working as it means the > gateway must forward the entire reference profile to the origin server with > every request. It's more efficient for the origin server to cache the > reference profile, but this can only be done with a profile reference. > Therefore I would discourage the OpenWave folks (or anyone else) from using > this approach. Anybody else thought about this? > > For more information on DELI see http://www-uk.hpl.hp.com/people/marbut/ > > Mark H. Butler > Research Scientist > HP Labs Bristol > > -----Original Message----- > From: Erich Izdepski [mailto:eizdepski@cysive.com] > Sent: 20 November 2001 14:20 > To: nick.denny@mci.co.uk > Cc: www-mobile@w3.org > Subject: RE: CC/PP profile repository overworked? > > The WAP gateway can (and I think openwave's will be soon) provide the CC/PP > profile to the origin server as a HTTP header. The gateway should be > managing its own cache of profiles that it has collected from other servers, > in the ideal case. For now, there are no other servers providing CC/PP data > about device hardware or software, meaning the gateway has to have its own > database of information. This is OK, it is simple for a gateway to create > CC/PP data from a local database of phone/handheld information and appended > it to the device headers. I know the Openwave gateway already appends header > information about its fax capabilities, so adding a CC/PP profile is not a > stretch. > > Erich Izdepski > > -----Original Message----- > From: nick.denny@mci.co.uk [mailto:nick.denny@mci.co.uk] > Sent: Tuesday, November 20, 2001 5:07 AM > To: www-mobile@w3.org > Subject: RE: CC/PP profile repository overworked? > > Hello again, > > Firstly thank you to Erich and Mark for your quick and helpful replies. > > Whilst reading the CC/PP requirements and architecture document > (specifically section 2.2) I noticed that in the WAP implementation, the > WAP gateway appears to resolve the profile URL and retreive the profile. > Is this correct? And if so, what is the Origin Server sent? Is it the > URL to the profile repository, in which case why does the WAP gateway > have to resolve it? Or is it a URL to the cached information in the > gateway? > > Many thanks, > > Nick Denny > nick.denny@mci.co.uk -- ++++++++++++++++++++++++++++++++++++ Johan Hjelm, Senior Specialist Ericsson Research Japan "Do you want to sell sugar water or change the world" is the wrong question. The right question is: "How do you change the world by selling sugar water?" Read more about my recent book http://www.wireless-information.net ************************************
Received on Wednesday, 21 November 2001 18:41:59 UTC