RE: Mobile phone capabilities list?

>the User-Agent header is not necessarily the definitive way to discover 
>the client properties, as any blind user with a screen reader 
>observing their browsing activity will tell you...

I suspect this points directly to the heart of the problem and explains why
the industry has failed to deliver a decent solution so far:
you want to make too many people happy at the same time!

What I find really weird is that as early as 2000 I was pointing out that
CC/PP was not very relevant for developers because it did not show up as
anything directly usable by anyone. Developers needed water and CC/PP was
providing a boring and strictly theory-based lesson on the nature of oxygen
and hydrogen.
Those that supported CC/PP replied to my objections that providing the tool
would be the responsibility of the industry, while the standard bodies would
provide the foundation for those solutions.
I think that WURFL demonstrated that they were wrong and I was right.
Standard bodies should provide complete solutions and reference
implementations.
The industry should provide extended solutions and better-performing
implementations of the standard. The blind would be much better server by
companies that build devices and reformatting solutions for the blind.
Demanding that everyone builds content and device descriptors which include
"blind-friendly" capabilities would not work in one thousand years: that
model sounds very noble, but it is flawed. Let's be real, even communism had
noble intentions, but look at where they got ;)

Luca



-----Original Message-----
From: Rotan Hanrahan [mailto:Rotan.Hanrahan@MobileAware.com] 
Sent: 26 July 2005 00:16
To: Luca Passani; public-ddwg@w3.org; www-mobile@w3.org
Subject: RE: Mobile phone capabilities list?

In case my point was missed: for a device to operate on a carrier's network
there must be an IMEI somewhere in the pipeline, but you cannot always
assume that the IMEI can be reliably mapped to the device that is actually
making the requests.
 
The WAI people have had this problem for years. They've often tried to
explain that the User-Agent header is not necessarily the definitive way to
discover the client properties, as any blind user with a screen reader
observing their browsing activity will tell you...
 
CC/PP made a step closer, and lack of implementation results in some steps
backward. Hopefully this won't be the case for too much longer. (Yes, I said
"hopefully". I can't make any committments or predictions here.) Meanwhile,
UAs, IMEIs and other signature.pattern logic will have to do.
 
---Rotan.

	-----Original Message----- 
	From: Luca Passani [mailto:luca.passani@openwave.com] 
	Sent: Mon 25/07/2005 23:00 
	To: public-ddwg@w3.org; www-mobile@w3.org 
	Cc: 
	Subject: RE: Mobile phone capabilities list?
	
	



	>Sure, IMEI mapping might work in most use cases, but not all.
	
	Rotan, you wrote a very long email just to basically give yourself
an answer
	at the end ;)
	
	For those who may have missed it, WURFL is all about working in most
cases.
	The fact is that "work in most cases here, work in most cases there,
you are
	pretty soon talking about serving the right content to millions of
	devices..."
	
	Luca
	
	-----Original Message-----
	From: Rotan Hanrahan [mailto:Rotan.Hanrahan@MobileAware.com]
	Sent: 25 July 2005 22:49
	To: Luca Passani; public-ddwg@w3.org; www-mobile@w3.org
	Subject: RE: Mobile phone capabilities list?
	
	One of the mobile devices I use on a regular basis is a
wireless-enabled
	iPaq. I use it at wifi hotspots, particularly at airports and cafes.
Its
	communication pathway does not involve what you would describe as a
mobile
	carrier. It does not have a SIM card, and obviously does not have an
IMEI.
	Yet I consider this device to be a legitimate mobile device.
	
	I also have a GPRS card. It has an IMEI. But you can't tell from the
IMEI if
	I have inserted the card into one of my laptops, my tablet or that
slightly
	older iPaq I have that has a PCMCIA adaptor sleeve. And what about
when I
	used to have the GPRS plugged into my old notebook and used
"connection
	sharing" to link my iPaq via ad-hoc so it could surf?
	
	Sure, IMEI mapping might work in most use cases, but not all.
	
	---Rotan.
	
	        -----Original Message-----
	        From: Luca Passani [mailto:luca.passani@openwave.com]
	        Sent: Mon 25/07/2005 19:39
	        To: public-ddwg@w3.org; www-mobile@w3.org
	        Cc:
	        Subject: RE: Mobile phone capabilities list?
	       
	       
	
	        This is an interesting point, which brings about two
questions:
	
	        
	
	        -          since you work for O2, I am assuming you know
better.
	Honestly, I was assuming that there is no such thing as a device
without
	IMEI as long as it is accepted on a carrier's Network. Don't
BlackBerry's
	have IMEIs? I know that operators have databases of IMEI and they
are
	building services on top of IMEI info.
	
	        -          Does O2 possess a way to associate IMEI to device
	capabilities? if yes, how is this achieved?
	
	        
	
	        Luca
	
	        
	
	       
	  _____ 
	
	
	        From: Holley Kevin (Centre) [mailto:Kevin.Holley@O2.com]
	        Sent: 25 July 2005 17:28
	        To: Luca Passani; public-ddwg@w3.org; www-mobile@w3.org
	        Subject: RE: Mobile phone capabilities list?
	
	        
	
	        So what happens if the mobile device doesn't have an IMEI?
	
	        
	
	        For example, a PDA based browser.
	
	        
	
	        Regards,
	
	        
	
	        Kevin
	
	        
	
	                -----Original Message-----
	                From: public-ddwg-request@w3.org
	[mailto:public-ddwg-request@w3.org] On Behalf Of Luca Passani
	                Sent: 22 July 2005 00:10
	                To: public-ddwg@w3.org; www-mobile@w3.org
	                Subject: RE: Mobile phone capabilities list?
	
	                Yes, this is something we have discussed quite a few
times
	in the WURFL community. The idea is to have an extra table to match
the
	first part of the IMEI with a WURFL ID. This would allow an operator
to
	easily detect device capabilities even without an HTTP Request
coming from
	subscriber device.
	
	                The reason why we have not embarked in such a
project is
	that developers typically do not have access to a device IMEI to
start with.
	
	                Having said this, there is increasing interest in
WURFL
	coming from operators, so I would say that IMEI support in WURFL is
bound to
	happen sooner or later.
	
	                If you like this proposition (and you have a
database of
	IMEI to share and expertise in the field), please contact me
offline. We
	could work together on this for the developer community's benefit.
	
	                
	
	                Thanks 
	
	                
	
	                Luca
	
	                
	
	               
	  _____ 
	
	
	                From: public-ddwg-request@w3.org
	[mailto:public-ddwg-request@w3.org] On Behalf Of Victor Servin
	                Sent: 21 July 2005 14:55
	                To: Rotan Hanrahan
	                Cc: public-ddwg@w3.org; www-mobile@w3.org; Steve
Parker
	                Subject: Re: Mobile phone capabilities list?
	
	                
	
	                well in the way i see it most mobile development
today, are
	least for phones, are made towards content delivery and related
things so u
	usuallay need full information about phonecapabilities i mean gprs
type,
	Egprs type, Audio compatibility, video compatibility and so on. It
will be
	very difficult to fullfill the needs of several companies and
developers but
	it would be good to create a more standarized and extensible model
to do it.
	It would be also great to improve IMEI databases cause if we think
uaprofs
	are difficult to deal with, imei's are impossible. Its there any
project to
	try to merge this two identifiers. In the end both of then are
usefull to
	describe the same device, at least when we talk about cell phones.
	
	                VJS
	               
	                
	
	                On 7/21/05, Rotan Hanrahan
<Rotan.Hanrahan@mobileaware...com
	<mailto:Rotan.Hanrahan@mobileaware.com> > wrote:
	
	                Several companies create and maintain their own
validated
	device information repositories, which are supersets of the
information
	available in public. However, it takes great effort to create these
	repositories and they are generally created in support of
specialised
	products. As a consequence, these repositories are out of reach
because they
	are expensive. I am pleased to report that certain key suppliers of
such
	repositories/products are participating in W3C MWI, with the hope
that their
	experience may be applied to the situation that you suggest is the
case
	today. An extensible, accurate, verified, trusted baseline
repository of
	device descriptions is one of the items on the table, which requires
the
	participants to examine carefully how such a repository might
operate. Much
	of the work will be conducted with input from the wider community,
so I
	welcome and encourage the feedback expressed on the public lists.
	
	                
	
	                ---Rotan
	
	                
	
	                -----Original Message-----
	                From: Steve Parker [mailto: sparker@well.com
	<mailto:sparker@well.com> ]
	                Sent: 21 July 2005 00:30
	                To: Rotan Hanrahan; Holley Kevin (Centre);
www-mobile@w3.org
	                Cc: public-ddwg@w3.org
	                Subject: RE: Mobile phone capabilities list?
	
	                Formally, these are certainly the right
standards/groups,
	but the track record is disappointing in practise. In my experience,
the
	UAProf info actually supplied is not necessarily accurate or
complete. The
	URLs are not always present or correct. There is no mechanism or
procedure
	for correcting it - its entirely at the manufacturers' whim. Even
when the
	data are ok, there's a lot of useful parameters missing from the
standard.
	There's supposed to be a Java API, but I had to report a bug in the
JSR
	reference implementation months after it was approved. It's very
frustrating
	to anyone actually trying to cater for all the different devices
right now.
	Standards are one thing, but to get something working, now, WURFL is
the
	only show in town. I'm not an open source zealot, but WURFL has gone
further
	faster than the standards bodies. It works as advertised, it's
responsive,
	it's simple to use, it's user extensible .
	
	                
	
	                Steve
	
	                        -----Original Message-----
	                        From: www-mobile-request@w3.org
	[mailto:www-mobile-request@w3.org]On Behalf Of Rotan Hanrahan
	                        Sent: Wednesday, July 20, 2005 2:07 PM
	                        To: Holley Kevin (Centre); www-mobile@w3.org
	                        Cc: public-ddwg@w3.org
	                        Subject: RE: Mobile phone capabilities list?
	
	                        The UAProf information, where provided and
	validated, can provide some essential and objective information
about mobile
	devices. It has been recognised, however, that in many domains of
content
	authoring and adaptation that such information is insufficient. The
DDWG
	will be exploring the bigger picture, and looking at ways that a
general
	device description repository could be achieved, such that it can
encompass
	UAProf and other sources of information, avoiding replication of
services,
	and providing the necessary features of discovery, trust, efficiency
and
	related information management issues. The DDWG is specifically
directed to
	liaise with UAProf and other related groups to this end. Planned W3C
Notes
	will explain in further detail, and these shall get a public airing
during
	this year. Input from interested parties via the public mailing list
will be
	encouraged. The group will also solicit specific information from
key
	parties where appropriate.
	
	                        
	
	                        I hope this adds some clarity.
	
	                        
	
	                        ---Rotan.
	
	                        
	
	                         [ ... see mailing list archive for previous
	messages ... ]
	
	                
	
	        =====================================================
	
	        This electronic message contains information from O2 which
may be
	privileged or confidential. The information is intended to be for
the use of
	the individual(s) or entity named above. If you are not the intended
	recipient be aware that any disclosure, copying distribution or use
of the
	contents of this information is prohibited. If you have received
this
	electronic message in error, please notify us by telephone or email
(to the
	numbers or address above) immediately.
	
	        =====================================================
	
	
	
	

Received on Tuesday, 26 July 2005 07:08:57 UTC