RE: CC/PP profile repository overworked?

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

Received on Wednesday, 21 November 2001 13:13:07 UTC