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 11:00:03 UTC