W3C home > Mailing lists > Public > public-ddwg@w3.org > July 2005

RE: Mobile phone capabilities list?

From: Rotan Hanrahan <Rotan.Hanrahan@MobileAware.com>
Date: Tue, 26 Jul 2005 10:42:08 +0100
Message-ID: <D9BC812593BC2E44A803E6765FFA5E2D92D176@gpo.mobileaware.com>
To: "Luca Passani" <luca.passani@openwave.com>, <public-ddwg@w3.org>, <www-mobile@w3.org>

Whether you are blind because of a problem with your eyes, or blind because the law says you are not permitted to look at your screen while driving your automobile, the point remains relevant.

Yes, I aim to make as many people happy as is possible and practical.

CC/PP needs a vocabulary, and a means for extending it, or it will fail. The Device Independence Working Group currently has the responsibility of doing this.

Many standards bodies only have sufficient resources (supplied through their membership) to examine issues and produce designs that will address these issues. The expectation is that the agreement to a standard will encourage compliant implementation by the membership, and ultimately by the wider community. If a standards body is expected to construct a reference, or a full implementation, then the membership must resource this work. This is not always possible.

The W3C, contrary to some beliefs, is not a standards body. It issues Recommendations. These result from considerable effort by the W3C membership, and are generally reflective of a consensus among the membership. The quality of this work is such that the general community has considerable trust in these Recommendations, and therefore they are usually adopted, eventually. The lack of the status of "standard", however, means that compliance is not an enforceable requirement, and so adoption can take some time to occur. The only way the W3C has to bring about timely adoption is by demonstrating the value that will result from such adoption.

In the case of CC/PP, it will be up to the W3C to demonstrate (once a vocabulary is ready) that there are stong benefits to obtain from adoption. To obtain wider acceptance, the development of the next phase of CC/PP will require support/input from the very people who are pushing to implement it, because of the growing issues they are facing with regard to device characteristics. These are the device manufacturers and content adaptation specialists. At this point in time, I see the OMA UAProf sub-working group as having a leadership role, working in conjunction with the DI and DD groups in W3C, and through the DD group to encompass as many others as possible and practical. This will obviously include input from WURFL, which has valuable practical experience to share.

Finally, regarding the blind (and any others who are impacted by constrained abilities, whether for medical or environmental reasons), I will never ignore their needs. I don't see this as a noble position. I see this as a correct position. (And I don't think it's too hard to facilitate this community within our technology.)


-----Original Message-----
From: Luca Passani [mailto:luca.passani@openwave.com]
Sent: 26 July 2005 08:09
To: public-ddwg@w3.org; www-mobile@w3.org
Subject: 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
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 ;)


-----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.

	-----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 
	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
	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
	-----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
	iPaq. I use it at wifi hotspots, particularly at airports and cafes.
	communication pathway does not involve what you would describe as a
	carrier. It does not have a SIM card, and obviously does not have an
	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
	I have inserted the card into one of my laptops, my tablet or that
	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
	sharing" to link my iPaq via ad-hoc so it could surf?
	Sure, IMEI mapping might work in most use cases, but not all.
  for the rest, see the email archive at
Received on Tuesday, 26 July 2005 09:42:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:12 UTC