2 Use Cases
2.1 Certification
Provider
Ace Content Provision has a substantial desktop presence and wants to
reach a mobile audience with its new service. Naturally it is keen to have
its content display as well as possible on mobile devices and so develops its
web site in accordance with the Best Practices.
Ace is keen to advertise the existence of its mobile tailored services and
show that its high quality brand value extends to this area. It believes that
the mobileOK claim will carry more weight, especially among search engines
tuned to mobile devices, if endorsed by a trusted third party. This is
particularly true of those claims related to non machine-testable aspects of
mobileOK.
One of Ace Content Provision's main distribution channels is a mobile
network operator that requires content on its portal to be certified as being
mobileOK by one of a short list of preferred certification providers. In
order to offer a flexible and competitive service, the certification provider
offers several levels of service. These range from automated checking of
machine-testable Best Practices through to frequent checks by human
reviewers. For Ace Content Provision, this is worthwhile as an ongoing
service. For other providers the balance of cost and assurance is best met by
assessment at service launch and on major update thereafter.
2.2 Content
Adaptation
A content developer wants to create high quality user experiences on
multiple devices. Sensibly, the developer chooses to use an adaptation
approach which supports mobileOK. They create device independent content
together with styling and layout, using W3C standards such as DIAL and
CSS.
When a device makes a request, the adaptation system uses the various
materials provided by the author to construct and deliver an appropriate page
that conforms to mobileOK. It automatically marks the page with the mobileOK
label. If the author has requested inclusion of the mobileOK logo, the
adaptation system adds it to the page.
2.3 Content Syndication
/ Aggregator
A content syndicator / aggregator gets content from many sources. Some may
be internal to the company, some may be external partner companies; in fact
some content from partners can be sent directly to the client using inclusion
via iFrames for example. In short, the content syndicator has, in some sense,
very little control over the syndicated content.
Since the mobileOK label can only apply to the full page delivered to the
end user, the content syndicator must ensure in some fashion that the content
from partners does not invalidate the label. Thus the syndicator wants
partners to make mobileOK conformance claims about their content to which
they can be held accountable. This may include information about who is
making the claim.
2.4 Individual Content
Author
Joe Lambda wants to make a web site about his holidays for a couple of
friends to follow, and be sure that it can be read on mobile phones. He reads
the mobileOK documents, and makes sure he follows the requirements, so he can
put the mark on his pages and his friends can check they will work before
they download them.
The use case requires no-cost use of the label and that the label should
be sufficiently simple that it can be added by the normal processes used for
web development.
It would be nice to have tools to assist in testing, to add the label when
tests have been met, and to note that something important has changed and
that content needs to be re-tested.
2.5 Search Engine
A search engine wants to provide search services over mobile content for
the benefit of its mobile users. When crawling the web it wants to easily
discover all content that is usable to a mobile device, especially content
designed specifically for mobile devices. It wants to evaluate how good the
mobile content is and index it. When serving queries from mobile devices, it
wants to return the best mobile content that matches the query.
One might imagine several things a search engine would want from the
mobileOK label. The one that seems vital to making mobileOK useful to the
search engine is detecting that a page at least says it is mobileOK and thus
is trying to be a good mobile page.
There are a couple things that would be nice to have. First is an easy way
to discover many mobileOK resources at once -- for example all mobileOK URL
in a directory or domain. Next is a way to at least partially verify that a
page does comply with mobileOK tests as claimed. Last is a way to identify
claims of partial conformance, so that the search engine can customize its
offerings to a particular profile of requirements. For example in a real use
case, I have a phone that has a certain set of constraints, but is much more
powerful than the baseline device -- specifically I don't care whether
content relies on JavaScript or not, since my browser supports it, so I want
content that meets various other requirements whether or not they meet any
requirements on script.
2.6 Software
Developer
A software developer is prioritizing fixing problems in rendering content
appropriately. Being able to gather a collection of mobileOK content provides
a useful test set, that allows prioritizing development based on what we
trust to be the approach to content that more people will be using -- chasing
a growing, rather than diminishing, market.
So the use case would require a discoverability mechanism for mobileOK
content, and people using mobileOK.
It would be very helpful to have some reasonably reliable and simple
method of verifying the claim.
2.7 Operator
An operator might use the mobileOK label to predict which content and
sites would work better on the mobile devices of its customers. By detecting
the existence of this label, an operator might apply different prices to the
data traffic, provide better network caching for those sites and in some
cases enrich the communication (policies at network transcoders, more
parameters, etc.).
2.8 Accepting or
Rejecting a mobileOK claim
An agent is set to crawl the Web to collect content to be presented in an
ATOM feed that is updated daily. Several criteria are used sequentially to
decide whether content resolved at a particular URI should be included or
not, including mobileOK conformance.
The crawler detects a mobileOK label describing content at
http://mobile.example.org. The label itself comes from a server the crawler
recognizes as being trusted. Although the label is digitally signed, for
efficiency, this is not checked before the crawler passes the content on to
the next stage in the evaluation process for possible inclusion in the ATOM
feed.
At http://new.example.org content is again described by a mobileOK label.
This time, however, the label is on a server the crawler has not encountered
before and so it does not know, yet, whether to trust the claims or not. The
data in the label carries a valid digital signature and so the content is
passed on to the next stage in the evaluation process for possible inclusion
in the ATOM feed. If it is subsequently included, the newly discovered server
will be added to the list of trusted sources as will the digital
certificate.
Finally the crawler discovers content at http://bad.example.org that is
again claimed to be mobileOK. The server is not recognized and the digital
signature is not valid for the data in the label. It is therefore rejected
and content is not forwarded to the next stage in the evaluation process.
3 Requirements for
mobileOK
The following requirements were considered in the development of
mobileOK.
- Machine-discoverable
- The mobileOK label must be discoverable by a machine.
- Self-labeling
- It must be possible to label content as mobileOK without the need to
acquire specialized tools, expend a disproportionate amount of effort,
and without the involvement of a third party. Anyone may label content
as mobileOK, including its author. See use case A.5.
- In other words, it should be possible for anyone with a reasonable
developers' knowledge of Web technology and the mobileOK tests to check
and label content according to both schemes.
- Third-party labeling
- It must be possible for a third party -- someone other than the
author or host -- to claim that content and its delivery are mobileOK.
See use cases A.1, A.2, and A.3.
- List of mobileOK Resources
- It must be possible to publish and locate listings of one or more
resources which bear the mobileOK label. See use cases A.1, A.6.
- Partial Conformance
- In addition to indicating whether a resource is mobileOK, it must be
possible to indicate partial conformance to the mobileOK test suite,
ideally at the level of individual tests. See use case A.5.
- Who
- It must be possible to determine who is claiming that the content is
mobileOK. See use case A.3.
- Version
- It must be possible to determine which version of the mobileOK label
is being claimed. See use cases A.1 and A.3.
- Authenticity
- It must be possible for a third party to verify that a mobileOK claim
was actually made by the party named in the claim, perhaps through the
use of digital signatures. See use cases A.3, A.8 and possibly A.5.
- Non-forgeability
- It must be possible to make a mobileOK claim in a way that is very
hard, if not impossible, to forge or replicate maliciously. See use
case A.8.