W3C mobileOK Scheme 1.0

Abstract

The mobileOK scheme allows content providers to promote their content as being suitable for use on very basic mobile devices. From a user's perspective, mobile search engines can increase the rankings of mobile friendly content so provide swifter access to more usable content. This document sets out exactly what a claim provides an overview of conformance with mobileOK means the scheme and how to make references the documentation that composes it.

Table of Contents

1. The mobileOK Scheme

mobileOK is designed to improve the Web experience for users of mobile devices and to reward by rewarding content providers and service operators that adhere to good practice when developing for mobile. It is a claim that delivering content dereferenced from a given URI conforms to them.

mobileOK Basic 1.0 Tests [ mobileOK ] and hence will provide at least a functional user experience on mobile devices. The claim says nothing about what may be made by the content publisher themselves delivered to non-mobile devices; furthermore, mobileOK does not imply endorsement or any third party. The sole basis for making a legitimate claim suitability of conformance with content. For example, it must not be assumed that mobileOK content is adherence to the of higher informational value, is more reliable, more trustworthy, is or is not appropriate for children etc.

1.1 mobileOK Basic Tests 1.0

mobileOK Basic Tests 1.0 [ mobileOK ]. That Recommendation sets out ] specifies a number of tests that content HTTP responses must pass when a URI is requested with a specific set of HTTP headers in order the request. The tests are designed to be confident of displaying machine processable and to provide confidence that content will display well across a wide variety of on very basic mobile devices.

1.2 Mobile Web Best Practices 1.0

mobileOK Basic Tests 1.0 is itself based on Mobile Web Best Practices 1.0 [ BP ], which gives provides a set of 60 sixty guidelines for making content work well across a wide variety of mobile devices.

1.3 The Default Delivery Context

The HTTP Request headers used in mobileOK turns the Best Practice Statements into machine processable deterministic tests applicable to baseline devices, and specifically to the Basic Tests 1.0 identify a hypothetical user agent called the "Default Delivery Context" (DDC). A claim The values of mobileOK may only be made the key properties of a URI that when dereferenced in the manner described in [mobileOK] yields DDC (screen width, formats supported and other basic characteristics) are set at the minimum possible, while still supporting a Web experience.

The DDC is thus not a target to aspire to, it merely sets a base line below which content providers do not need to provide their content. It is expected that passes all the mobileOK Basic Tests. content providers, as well as targetting DDC level devices, will wish also to provide non-mobileOK experiences for more advanced mobile devices.

1.4 mobileOK Checker

A suite of software known as package called the mobileOK Checker, Checker [ CHECK ], has been developed by the Best Practices Working Group to provide automated checking of conformance. This tool The package is in Java, and is open source. It is also available via under a W3C License .

W3C has created a Web interface as part of the W3C Validator , which uses this package. Other Web based checkers, by dotMobi (see ready.mobi ) and CTIC (see TAWDIS ) have also been created that adhere to the mobileOK Basic Tests 1.0 [ CHECK mobileOK ].

2 Claiming Conformance

Claims of conformance with Content Providers may wish to identify that their content is mobileOK should be discoverable primarily by machines and, optionally, by humans. In practice, this conformant. This means applying metadata that it can be requested so that the response conforms to mobileOK Basic Tests 1.0 [ mobileOK ] and hence will provide at least a functional user experience on mobile devices. A claim may only be made of a URI that when dereferenced in the manner described in [ mobileOK ] yields a response that passes all the tests contained in mobileOK Basic Tests 1.0. Such a claim says nothing about other experiences that may be provided at the same URI, when dereferenced in a different way (e.g. with different User-Agent and Accept HTTP headers).

2.1 The mobileOK Trustmark

W3C provides a mobileOK icon (trustmark) that represents a claim that the content and, where relevant, displaying on which the icon is found is mobileOK logo. conformant as descibed above.

The latter trustmark is most appropriately used on desktop representations of a resource for which a mobileOK representation is also available. In such a situation it acts as a signal to a desktop user that the content or service they're they are using is also available on a mobile device. Display of the mobileOK logo trustmark is usually inappropriate on a mobile device since whether the content is usable on their device or not will be fully apparent without it.

When displaying a mobileOK says nothing about what may trustmark, the image should be delivered to non-mobile devices; furthermore, mobileOK does not imply endorsement or suitability of content. For example, it must served from the same server as the resource, not be assumed from the W3C site. Note that mobileOK content is of higher informational value, the image is more reliable, more trustworthy, provided in PNG format and hence is or it not appropriate suitable for children etc. 1.1 Who is use on mobileOK For? representations of pages, though it may be used on other representations.

mobileOK has value at many points in the content authoring The trustmark is issued under W3C copyright and delivery chain for mobile devices. These are developed in more detail may only be used in the Use Cases , but the main audiences are briefly listed here: Content Developers Developers who create content which follows Mobile Web Best Practices have added value for mobile users. They can advertise this to consumers of their content through making a machine-readable claim of conformance accordance with mobileOK. Tools Likewise, tools that can produce, parse, adapt or manipulate the W3C mobileOK content (browsers, content management systems, authoring tools, content adaptation systems, etc.) add value for authors, and can advertise this capability. Content Providers Sites license [ LICENSE ], the key feature being that are concerned with providing a quality experience to mobile users can look for a mobileOK claim it may only be used in representations of resources that, when acquiring content and tools. Content Discovery Services Search engines, content aggregators, and other services which locate content for mobile devices can look for a mobileOK claim and possibly prioritize dereferenced in accordance with the mobileOK content. Content Consumers Basic Tests 1.0, pass those tests.

2.2 Machine Readable Identification

End consumers To enhance discoverability of content may also treat mobileOK content differently, preferring sites that advertise mobileOK content. Certification Provider Certification content, providers may wish to offer to certify conformance with mobileOK; entities such identify their material as content providers that come to rely on mobile content may require more verification that content they provide is mobileOK. 1.2 Relationships to Other Recommendations Insert a picture like the one at the F2F 1.2.1 Relationship to mobile BP Not sure how much detail we need here, could be that we flesh out the intro a bit more. 1.2.2 Relationship to Basic Tests Not sure how much detail we need here, could be that we flesh out the intro a bit more. 1.2.3 Relationship to being mobileOK Checker Not sure how much detail we need here, could be that we flesh out the intro a bit more. 2. using POWDER (see Claiming mobileOK Conformance As noted above, a claim of conformance with mobileOK should be made in such a way that is machine-readable which, in practical terms means associating the mobileOK resource with metadata in some way. Visual, i.e. human readable, cues that a given URI is capable of yielding mobileOK content may also be provided but this is secondary. It is noteworthy that a claim of conformance with mobileOK is always associated with the person, organization or other entity that makes it. Using POWDER ). Content providers should be mindful of the (obvious) fact that if an end user regards "Organization A" as more trustworthy than "Organization B," then be linked to a claim of mobileOK conformance made by organization A will have the greater value. Need to explain somewhere how it can be that two different orgs can express an opinion, maybe move the above para. 2.1 mobileOK as described in RDF To support claims of conformance with mobileOK, we define a one-class RDF vocabulary. The namespace is http://www.w3.org/2008/06/mobileOK# and the class has the name Conformant . The following RDF triple therefore asserts that some URI, u is mobileOK conformant: < u > rdf:type < http://www.w3.org/2008/06/mobileOK#> 2.2.3 Linking Resources to Claims .

2.2.1 Claiming mobileOK Conformance using Using POWDER

The Protocol for Web Description Resources [ POWDER ] provides a means through which a claim of mobileOK conformance may be made about many resources at once, such as all those available from a Web site. Importantly, POWDER also provides a means of identifying the person, organization or entity that made the claim. These two features make POWDER's Description Resources an ideal transport mechanism for mobileOK conformance claims (mobileOK was a key use case for POWDER).

In the following (fictitious) example, on 25th June 2008, 2008 (line 5), the organization described at http://www.example.com/company.rdf#me (line 4) claimed that all the resources available from example.com (lines 9-11) were mobileOK. mobileOK (line 13). This makes use of a one-class RDF vocabulary with namespace http://www.w3.org/2008/06/mobileOK# and class name Conformant .

1  <?xml version="1.0"?>
2  <powder xmlns="http://www.w3.org/2007/05/powder#">
3    <attribution>
4      <issuedby src="http://www.example.com/company.rdf#me" />
5      <issued>2008-06-25T00:00:00</issued>
6      <supportedby src="http://validator.w3.org/mobile/" />

6      <supportedby src="http://example.net/checker/" />

7    </attribution>
8    <dr>
9      <iriset>
10       <includehosts>example.com</includehosts>
11     </iriset>
12     <descriptorset>
13       <typeof src="http://www.w3.org/2008/06/mobileOK#Conformant" />
14       <displaytext>The example.com webiste conforms to mobileOK</displaytext>
15       <displayicon src="http://www.w3.org/ICONS/mobileOK.png" />

15       <displayicon src="http://www.example.com/images/mobileOK.png" />

16     </descriptorset>
17   </dr>
18
</powder>

http://www.example.com/company.rdf#me (line 4) should lead to an RDF resource that describes the entity (either the foaf:Agent or dcterms:Agent ) that provided the Description Resource. It is open to that organization to provide authentication methods to support its claim of mobileOK conformance. Note also in line 6 that POWDER's supportedby element has been used to refer to the mobileOK Checker, http://example.net/checker/, the implication being that the content of the described Web site has been tested using the Checker. that checker. Lines 14 and 15 provide textual and graphical data that user agents may display to end users.

2.2.2 Linking Resources to Claims using RDFa Note that the following would actually make the resource not mobileOK Basic, so furhter expalnation needed here HTML link Element

RDF Annotation [ RDFa ] can be used to embed a claim of All mobileOK conformance directly in an XHTML document as shown in resources are HTML. In the following example. 1 <html 2 xmlns="http://www.w3.org/1999/xhtml" version="XHTML+RDFa 1.0" 3 xmlns:mok="http://www.w3.org/2008/06/mobileOK#" > 4 <head typeof="mok:Conformant"> 5 <title>Document Title </title> 6 </head> The example a powder document is linked using the version link attribute on element (line 3). The value of the html rel element is optional but attribute, "describedby" is a clear signal to a processor that namespaced by the document contains RDF annotations. The typeof profile attribute on of the head is a shorthand way used element (line 2) in RDFa versions of HTML that support it.

1  <html xmlns="http://www.w3.org/1999/xhtml">
2     <head profile="http://www.w3.org/2007/11/powder-profile">
3        <link rel="describedby" href="powder.xml" type="text/powder+xml"/>
4        <title>Welcome to example.com </title>
5     </head>
6     <body>
7        <p>Today's content is ....</p>
8     </body>
9  </html>

2.2.3 Linking Resources to assert Claims using the HTTP rdf:type link relationship so that an RDFa-aware user agent will extract Header

In many application environments it can also be appropriate to use HTTP Link [ HTTP Link ] headers. The following header is semantically equivalent to the HTML link header above.

Link:
<powder.xml>;
rel="describedby"
type="text/powder+xml";

2.2.4 Other Forms of Claim

Other machine readable means of making a claim of mobileOK conformance are available. For example the following RDF triple: triple asserts that the URI http://example.com is mobileOK conformant:

< http://example.com > rdf:type < http://www.w3.org/2008/06/mobileOK#> http://www.w3.org/2008/06/mobileOK#conformant>

i.e. that the current document is an instance of the class Other forms of resources that conform to mobileOK. Note that using RDFa to claim conformance with mobileOK implies that the entity making the expressing a claim is the content creator. Furthermore, user agents are given no clue as to how they may authenticate the claim. Therefore this method should not be seen as an equivalent method to using POWDER. 2.4 The mobileOK Trustmark some stuff on the mark and where to find the license to use become available in the mark future.

3. Change Log TBD - if only it were clear what the previous document was! Basically re-wrote more or less everything, kept 'who is it for' and moved the use cases to an appendix. introduced the RDF vocab, POWDER and RDFa examples. 4. Acknowledgements

The editors would like to thank members of the BPWG for contributions of various kinds. and acknowledge significant written contributions from:

Previous editors of this document: Editors:

Sean Owen (Google) and Owen, Google

Charles MccathieNevile McCathieNevile, Opera Software). 5. Software

4. References

BP

Mobile Web Best Practices 1.0 . Jo Rabin, Charles McCathieNevile, W3C Recommendation 29 July 2008

BASIC

W3C mobileOK Basic Tests 1.0 . Sean Owen, Jo Rabin. W3C Working Draft 10 June 2008

CHECK

W3C mobileOK Checker . Dominique Hazaël-Massieux, François Daoust BPWG Checker Task Force

LICENSE

W3C mobileOK License @@version?? @@date?? (draft, member only link) .

POWDER

Protocol for Web Description Resources (POWDER): Description Resources . Phil Archer, Kevin Smith, Andrea Perego. W3C Working Draft 8 August 2008

RDFa

HTTP Link

RDFa in XHTML: Syntax and Processing HTTP Header Linking Ben Adida, Mark Birbeck, Shane McCarron, Steven Pemberton. W3C Candidate Recommendation 20 June Nottingham, Internet Draft, 3 July 2008 Appendix A: Use Cases and Requirements for mobileOK I'm not convinced that these appendices add value. A.1 Use Cases A.1.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. A.1.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. A.1.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. A.1.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. A.1.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. A.1.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. A.1.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.). A.1.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. A.2 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.1.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.1, A.1.2, and A.1.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.1, A.1.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.1.5. Who It must be possible to determine who is claiming that the content is mobileOK. See use case A.1.3. Version It must be possible to determine which version of the mobileOK label is being claimed. See use cases A.1.1 and A.1.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.1.3, A.1.8 and possibly A.1.5. Non-forgeability It must be possible (expires 9 January 2009, expected to make a mobileOK claim in a way that is very hard, if not impossible, advance to forge or replicate maliciously. See use case A.1.8. RFC status)