RE: CC/PP and UAProf implementations?

Hi Alexis

> New to the list I've spent some time perusing the list archive 
> and I've noticed the debate going on over the use of RDF and 
> an XML representation of RDF in CC/PP. This debate has 
> far-reaching implications as far as the future of UAProf 
> is concerned and I find it confusing to see UAProf adopted 
> while cc/pp is still in discussion.

Firstly I'm sorry you are confused. 

Well there are opinions here. One is that CC/PP
and UAProf are finished, and that all remains is for CC/PP 
to reach recommendation. This is the view of the current
CC/PP WG Members (Franklin Reynolds, Nokia, Graham Klyne,
NinebyNine, Kaz Kitagawa, Keio University) apart from me. 
Note though that the CC/PP WG is currently very small,
so I would argue that it may not be representative of the
CC/PP community at large. 

Also the WAP Forum seems to think that UAProf is finished
as it closed the UAProf email list, but I think this was 
premature as it is difficult to find systems (i.e. a complete
chain of client, gateway and server) using UAProf today. 

The other opinion is that CC/PP requires some revision. 
This is my point of view, and is based on the server API
I have implemented for CC/PP and UAProf
http://delicon.sourceforge.net/
for more details of the problems I have encountered see 
the tech reports available on my web page.
http://www-uk.hpl.hp.com/people/marbut/
So I've been arguing that we need to introduce some changes to
CC/PP. There are a few obvious errors that need fixing in UAProf
also (e.g. they should make sure the schemas are correct
RDF schema and put them at the URL indicated by the namespace)
but I agree that any changes introduced in CC/PP do need
to be backwardly compatible with UAProf. 

Employees of W3C member organisations can see the issues I've 
raised at 
http://www.w3.org/Mobile/CCPP/Group/CR/issues-2002-07-10.html
and are welcome to send comments on them to WWW-Mobile. 

I'm currently working on a proposal to tackle these issues
and simplify CC/PP. It's a work in progress at the moment,
but for more details see
http://www-uk.hpl.hp.com/people/marbut/proposal/ccpp_proposal.html

> The work on UAProf is indeed finished but I have not found 
> any non-trivial UAProf implementation in cellular phones, 
> the main deployment target. 

I've had difficulties testing real deployed devices as I 
have been unable to find any WAP gateways in the UK that support 
UAProf. However I understand from people working at other 
companies that the Mitsibushi Trium Eclipse does use both 
profile refs and profile diffs - perhaps some one can confirm this?

> None of the dynamic aspects of capability updates through 
> profile-diffs are implemented and I suspect that they aren't 
> going to be for quite a while given the level of complexity 
> that the whole RDF machinery requires on a cell phone 
> (can someone prove me wrong please?). 

Actually it shouldn't be too hard to do this on a cell-phone, 
you would just have a canned piece of RDF (well XML) and then 
insert values. So the device would not have to be RDF-aware 
to do this. However the server-side processor still has to 
"resolve" the profile and the profile-diff. I think UAProf 
defines this process more clearly than CC/PP, but there are 
some hidden complexities here. Specifically I think two key 
use cases of diffs on mobile phones are to change user language 
and turn sound on or off: however there are hidden complexities
here as I outline in my tech reports. 

>So UAProf on a cell phone does little more than "User-Agent" 
> since the cell phone profile cannot be updated during a WAP session.

Yes, but there is still some value in this as it means it 
is possible for servers to recognise new devices automatically; 
if we just recognise devices by user-agent strings then we 
have to configure servers for devices in advance. So although 
there are problems with current standards, I definitely think 
there is value in CC/PP and UAProf otherwise I wouldn't be 
working on it. 

> On the server-side, what is the impact of the java specification 
> request on cc/pp? Does that mean that CC/PP is being cast to stone?

No. My preference here would be to revise and simplify CC/PP
(along the lines of my proposal), get that approved with the W3C and 
then base the JSR on that. If necessary the JSR could produce a
document filling in some of the gaps that exist with CC/PP, and
then feed that back to the W3C.

I think the problem with CC/PP is that the W3C work has only considered
structure. It's only when you start to consider the protocol e.g.
refs and diffs that CC/PP becomes complicated, but the W3C
has not worked on this because generally the IETF works on protocols
whereas the W3C works on markup. This is why the W3C Recommendation
Track document does not discuss protocols. 

However, obviously this is just my view so whether this happens is a 
matter for the W3C, the CC/PP-WG and the JSR. If you have an opinion 
either way, I would encourage you to voice it. I'd be very interested
to know what you think and what you would prefer to see happen. 
 
> I'm a little bit concerned that the current lack of working 
> implementations on the client-side jeopardizes profile and 
> capability information exchange; 

Actually there are a number of implementations for clients e.g 
Ericsson T68, Ericsson T39 and Mitsibushi Trium. Intel have 
created a CC/PP proxy for Windows CE machines you can download 
from their developer site. The XSmiles Browser 
http://www.xsmiles.org 
also supports CC/PP.

I think the real problem is different companies are responsible
for clients than those responsible for devices, so someone has
to try putting combinations of these together in order to 
test them as a complete system. We've been doing quite a bit 
of interoperability testing with our server implementation, DELI, 
and I think it's fair to say that we haven't yet encountered a 
device that worked first time. This could be down to mistakes on 
my part or on the part of the client, but either way I think it 
points to the fact the standards are not sufficiently well defined
to guarantee interoperability. 

best regards

Mark H. Butler, PhD
W3C CC/PP Working Group Chair
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Monday, 15 July 2002 10:39:48 UTC