RE: CC/PP profile repository overworked?

Hello,

olivier.rovellotti@3tl.com wrote:
> Why not ask the manufacturer to maintain the profile 
> repository for the devices they are commercializing,
> that way we are putting the effort onto a commercial
> organization which should have the financial power 
> to make a good job of it.

As far as I understand, this is how the specifications expect the
Profile for devices to be hosted. However, I am still concerned with
quite how many hits a Profile Server would get.

From what I understand, Mark Butler's DELI program takes an End-to-end
view of CC/PP:

- A Mobile device specifies a URL in a WSP header, which points to the
Profile held on the manufacturer's server.
- This URL is then forwarded in a HTTP header to an Origin server.
- The Origin Server will then download the Profile and send back content
based upon this information, or will have the Profile in the cache
already, so won't need to download it again, until the Profile cache
expires (e.g. 24 hours).

This means that the Profile server will have to cope with every CC/PP
enabled site (which has the specific device visiting it) downloading a
Profile every time the cache expires (e.g 24 hours). This assumes that
servers do cache profiles, which I've not read to be a mandatory
requirement.

The other view ( Johan's second point) I don't quite understand:

 
Johan Hjelm wrote:
[snip]
> Secondly, the profile is cached in the proxy retrieving the 
> information for the client when it has been read once. So 
> the traffic will not be as large as it sounds. The WAP gateway
> acts as a HTTP 1.1 proxy on the  Internet side; at
> least, this was how we intended it to be implemented. The 
> profile-diff can actually be a difference from an empty profile
> (of course you have to send the empty profile first), this is
> how it is used to combine P3P with CC/PP in the PIMI method.


What I understand of this:

- A Mobile device specifies a URL in a WSP header, which points to the
Profile held on the manufacturer's server.
- The WAP proxy server will then download the Profile (if it is not
already cached).
- The WAP proxy server sends an HTTP request for the appropriate page,
with a Profile-Diff in the HTTP header containing all the Profile
information.
- The Origin server uses the profile information to send back the
requested content.

This means that the Profile Server would get fewer hits - once per WAP
proxy per cache-timeout time. However, this means that the HTTP headers
for each request would be ~10K in size. This also increases the effort
required by gateway manufacturers to support UAProf / CC/PP.

Apart from reducing the work required by the Profile Server, why is this
an advantage? The Origin server won't cache any profiles as it only
receives Profile-Diffs

Could someone explain which view is correct, or are both correct or am I
misunderstanding something? I realise the above examples are the most
basic examples, and ignore any user Profile-Diffs.

Thanks,

Nick Denny
nick.denny@mci.co.uk