How Would You Like That Served?

Some people access email with a desktop computer, a laptop computer, and a handheld, as well as a WAP-enabled cell phone. Each of these devices has a different set of capabilities. To help Web servers keep pace with heterogenous clients, the CC/PP protocol provides a way for clients and servers to exchange information about the client's capabilities and preferences.

An Everyday Use for RDF

RDF is seen by some as a cure for all ills. Others see it as too complex to be useful. In fact RDF is a kind of record containing properties about a web resource, which is why it was chosen by the CC/PP working group to describe device capabilities. In this context, a device equipped with a browser is considered a web resource, one which has properties like screen size, rendering capabilities, etc.

Details about CC/PP are publicly available., including details about the protocol itself. The existing CC/PP spec was submitted to the W3C as a NOTE and forms the basis of the CC/PP group's ongoing efforts. I won't describe the full protocol, but I will present a simple example to illustrate how a client tells a server about its capabilities.

CC/PP as HTTP Extension

CC/PP is an extension of the HTTP protocol. A client obtains a resource from a server with a GET request in which the client includes the device capabilities and user preferences. Ordinarily the clients add some HTTP headers to the GET verb such as the MIME type understood by the browser, the host name, and so on. CC/PP requests contain supplemental headers in addition to the basic ones recommended by the HTTP 1.1 specification. In the sample below, a mobile phone client requests a document and tells the server its capabilities.

GET /a-resource HTTP/1.1
Host: talvastudio
Opt:  "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=19 
19-Profile: "1-uKhJE/AEeeMzFSejsYshHg=="
19-Profile-Diff-1: <?xml version="1.0"?>
    <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
    xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
    xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
    <Description about="http://www.example.com/MyProfile"><ccpp:component>
    <Description about="http://www.example.com/Browser">
    <type resource="http://www.example.com/Schema#BrowserUA" />
    <uaprof:BrowserName>Mozilla</uaprof:BrowserName>
    <uaprof:BrowserVersion>5.0</uaprof:BrowserVersion>
    <uaprof:CcppAccept> <Bag> <li>text/plain</li> <li>text/vnd.wap.wml</li>
    </Bag> </uaprof:CcppAccept> </Description> </ccpp:component>
    </Description> </RDF>

GET verb is an HTTP 1.1 method used to request some resource. The Host header indicates the destination host. The Opt header, part of the CC/PP protocol, is used to tell to the server that the request includes an optional profile fulfillment. When the profile fulfillment is optional, the server may or may not adapt to the client's capabilities. If the client wanted to make this profile mandatory, the HTTP verb would have been M-GET and the header indicating the CC/PP protocol would have been Man.

CC/PP is based on the HTTP extension framework. An extension declaration indicates that this HTTP message includes an extension. In our context, the Opt or Man headers indicate that a CC/PP extension is included in an HTTP 1.1 request. The header's value "http://www.w3.org/1999/06/24-CCPPexchange" is the HTTP extension identifier. It tells a server that the request contains a CC/PP protocol extension. The ns attribute identifies the namespace. In contrast to XML namespace prefixes, HTTP namespace prefixes are delimited by a ":" character rather than "-". Both the 19-Profile and 19-Profile-Diff headers are part of the 19 namespace and therefore are also CC/PP headers.

The 19-Profile header consists of a digit and a digest. The digest is an MD5 message digest of the 19-Profile-Diff-1 header encoded with base64. The digit is found again at the end of the 19-Profile-Diff-1 header's name.

RDF in the Header

The most interesting header, from the XML developer's perspective, is 19-Profile-Diff-1, which contains an XML document. The header's value is a canonical XML document formed in accord with James Clark's Canonical XML specification. Since the publication of the CC/PP NOTE, however, the W3C's work on Canonical XML has progressed. 19-Profile-Diff-1 contains an RDF description.

<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
  xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
    <Description about="http://www.example.com/MyProfile">
        <ccpp:component>
            <Description about="http://www.example.com/Browser">
                <type resource="http://www.example.com/Schema#BrowserUA" />
                <uaprof:BrowserName>Mozilla</uaprof:BrowserName>
                <uaprof:BrowserVersion>5.0</uaprof:BrowserVersion>
                <uaprof:CcppAccept>
                <Bag>
                    <li>text/plain</li>
                    <li>text/vnd.wap.wml</li>
                </Bag>
                </uaprof:CcppAccept>
           </Description>
       </ccpp:component>
    </Description>
</RDF>

It's an XML document containing a description of the client's capabilities. It indicates that the client is a browser in the Mozilla family, that the client version is 5.0, and that it accepts plain text or WML encoded documents. Of course this is a minimal description. A more complete description would also contain the screen resolution, presence of a keyboard, voice recognition support, and so on. It might also contain user preferences: sound on or off, the user's favorite color, etc. CC/PP profile structures are publicly available.

Conclusion

CC/PP will be a key part of the coming pervasive Web since it provides a framework within which diverse clients can tell servers what they want or what they can do. It will allow servers to adapt to a client's needs. When CC/PP becomes a recommendation, RDF will become as pervasive as the Web itself.