Re: CC/PP profile repository overworked?

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