| The complementary DTDs of SyncML are the Meta Information DTD and the Device Information DTD. They are used by the protocols based on the usage of the Representation Protocol: the Synchronization Protocol and the Device Management Protocol [SDP02]. The Synchronization Protocol utilizes both the Meta Information DTD and the Device Information DTD. The Device Management Protocol only uses the Meta Information DTD. Meta Information DTD The purpose of the Meta Information DTD (MetInf DTD) is to provide a set of markups to be used by the SyncML DTD (i.e. the Representation Protocol) to identify meta-information associated with a SyncML command or a data item. In practice, it is hard to construct fully operational and meaningful SyncML Messages without the MetInf DTD (e.g., the format or type of a data item). There are a couple of clear advantages to separating the MetInf DTD from the Representation Protocol. First, the MetInf DTD can be reused with other technologies in addition to SyncML. Second, the representation of meta-information within the Representation Protocol is not tied to specific element types. This allows for additional meta-information element types targeted for specific purposes to be easily utilized within the Representation Protocol. The Meta Information DTD has a simple, flat structure. There are only two element types (Anchor and Mem) that have child elements. Actually, in practice, the usage of MetInf is even simpler. When the MetInf DTD is used within the Representation Protocol, the root element type (MetInf) is not used at all. The XML example below shows how to embed an element of the Meta Information DTD (NextNonce) inside a command of the Representation Protocol. <Status> <CmdID>12</CmdID><MsgRef>3</MsgRef> <CmdRef>45</CmdRef><Cmd>Add</Cmd> <TargetRef>./sync_DB</TargetRef> <Data>401</Data> <Item> <Meta> <NextNonce xmlns='syncml:metinf'> ZG9iZWhhdmUNCg== </NextNonce> </Meta> </Item> </Status> Although the MetInf DTD could be used outside SyncML, there are characteristics that closely link it to SyncML. For instance, the use of many element types of the MetInf DTD is not compelling outside a synchronization framework like SyncML. In addition, the MetInf DTD uses the same WBXML (Wireless Binary XML) binary tag code space[2] as the Representation Protocol, although the MetInf element types belong to a different XML namespace. [2] The WBXML binary tag code space defines binary tags to corresponding clear-text XML elements types.
MetInf element types The element types of the MetInf DTD can be divided into three different categories. The element types can be either related to actual content transferred in a SyncML Message, or to dynamic device characteristics, or to miscellaneous purposes. Table 7-1 shows the categories and the element types that belong to them. Table 7-1. MetInf Element Types within CategoriesCategory | Element Types |
|---|
Content related | Format, Mark, Size, Type, and Version | Dynamic device characteristics | Anchor, FreeID, FreeMem, Last, MaxMsgSize, MaxObjSize, Mem, Next, and SharedMem | Misc purposes | EMI, MetInf, and NextNonce |
The content-related element types help to specify the content completely. The Format element type is used to define whether the content is character-encoded or binary-encoded. The size of the content can also be specified. Utilize the Mark element type to do special marking, like specifying an email message as unread. Indicating the MIME type of the content is also possible with the Type element. The revision information for the content can be included in the Version element type. Below is an example of an Add command in which all these element types are utilized. The payload data is a calendar event with a size of 145 bytes and using the vCalendar 1.0 MIME type. <Add> <CmdID>12345</CmdID> <Meta> <Format xmlns='syncml:metinf'>chr</Format> <Mark xmlns='syncml:metinf'>final</Mark> <Size xmlns='syncml:metinf'>145</Size> <Type xmlns='syncml:metinf'>text/x-vcalendar</Type> <Version xmlns='syncml:metinf'>20000714T082300Z</Version> </Meta> <Item> <Source><LocURI>./2</LocURI></Source> <Data> BEGIN:VCALENDAR VERSION:1.0 BEGIN:VEVENT DTSTART:20020602T140000Z DTEND:20020602T150000Z SUMMARY:SyncML Meeting END:VEVENT END:VCALENDAR </Data> </Item> </Add> The SyncML specification allows for substantial flexibility for supporting content-related element types. Only the Format and Type element types are mandatory and must be implemented in SyncML products. The others are optional. Thus, the implementations using Mark, Size, or Version need to pay attention to whether they are supported in the recipient entity. The element types related to dynamic device characteristics are basically required to enable a Synchronization Protocol-based session between the Client and the Server. The Anchor element type, including Last and Next, is used to transfer sync anchors (i.e. markers) transferring the anchors allows a conformity check of a previous session, as described in Chapter 5. These anchor-related element types are mandatory for implementations supporting the Synchronization Protocol. MaxMsgSize can be used to indicate how large a SyncML Message (in bytes) a given device can receive. This information is included in the header of the SyncML Message. The maximum Message size can be specified either once for a session or for every Message transferred. This is one of the very basic element types to be supported for receiving SyncML Messages. Similar to MaxMsgSize, MaxObjSize is used to specify the maximum size of the largest object that can be received in any subsequent response Messages. The Mem element type with FreeID, FreeMem, and SharedMem includes information about free memory in a device or in a datastore. Support for these element types is optional for the Client, but Client implementations, in general, do support these element types, as they can provide clear benefits. These element types are usually sent to a Server during a SyncML session. The FreeID element type is used to indicate how many free locations are available for new data objects to be added to a device or to a datastore. For instance, this can be used if a SIM card (Subscriber Identity Module) with a static-sized memory is synchronized with a Server. FreeMem is used when a free amount is indicated in bytes. If the free memory is shared between datastores, then SharedMem should be specified. The utilization of the content in these element types can decrease the amount of data to be transferred between the entities if the receiving entity (e.g. a Client) is close to running out of memory or IDs. The third category of MetInf element types is used for miscellaneous purposes. In this category, there are three element types: EMI (Experimental Meta Information), MetInf, and NextNonce. The EMI element type can be used to specify nonstandard, experimental extensions. Also, the root element type of the MetInf DTD belongs to this category. Its usage is quite rare, as the child element types can directly be used when utilized within the Representation Protocol. The third element type in this category, NextNonce, is needed when challenging for a MD5 digest authentication. Below is an example how to use the NextNonce element type within the Chal element type of the Representation Protocol. <Chal> <Meta> <Type xmlns='syncml:metinf'>syncml:auth-md5</Type> <NextNonce xmlns='syncml:metinf'>Tm9uY2U=</NextNonce> </Meta> </Chal> From the miscellaneous element types, MetInf and NextNonce must be supported. EMI, as its description already hints, is an optional element type. WBXML encoding Like the element types of the SyncML DTD, the MetInf element types can be encoded either using clear-text XML or WBXML (binary tokenized) [WBXML01]. When using SyncML over a wireless network such a GSM network, WBXML is commonly used to decrease the amount of data to be transferred. In both XML and WBXML, the MetInf element types can be used within a SyncML Message. Thus, there must be a way to specify the change of a namespace. As seen in multiple examples earlier, the change of the namespace in XML is done according to the XML standard specified by the World Wide Web Consortium (W3C). In WBXML, specified by the WAP Forum®, there is no standardized way to change the namespace within a WBXML document. Thus, the SyncML Initiative has specified a different WBXML code page for the MetInf DTD. This code page uses the same WBXML code space[3] as the Representation Protocol. The Representation Protocol defines the first code page (0x00) of the SyncML DTD code space to belong to the element types of the SyncML DTD. The second code page (0x01) is then dedicated to the MetInf element types. In this way, these namespaces can be enabled within a WBXML document. [3] A code space can include multiple code pages. SyncML has utilized this functionality by using a separate code page for the SyncML DTD and for the MetInf DTD.
When using the WBXML encoding for the MetInf DTD within a SyncML Message, the code page must be changed in the middle of the WBXML document representing the SyncML Message. Actually, when using an element type from the MetInf DTD, two code page switches are needed. First, the switch for using the MetInf DTD is needed. After the MetInf element type or types are used, then a switch back to the SyncML DTD is required. Below is an XML example showing how to embed the Next element type inside the Data element type of the Representation Protocol. <Data> <Next xmlns='syncml:metinf'>20000522T093223Z</Next> </Data> In a WBXML tokenized form, this would look like: 4F 00 01 4A C3 10 "2" "0" "0" "0" "0" "5" "2" "2" "T" "0" "9" "3" "2" "2" "3" "Z" 01 00 00 01 Table 7-2 shows which binary tokens correspond to the text tags. Also, the change of the code page is included. Table 7-2. Correspondence of Text and Binary TagsBinary Token | Description |
|---|
4F | Corresponds to the <Data> tag. | 00 | Specifies a code page switch. | 01 | Specifies which code page (now, the MetInf code page) is to be used. | 4A | Corresponds to the <Next> tag. | C3 | Specifies that an opaque data follow. | 10 | Specifies the length of the opaque data (0x10 bytes) | "2" "0" "0" "0" "0" "5" "2" "2" "T" "0" "9" "3" "2" "2" "3" "Z" | Specifies the string '20000522T093223Z'. | 01 | Corresponds to the </Next> tag. | 00 | Specifies a code page switch | 00 | Specifies which code page (now, the SyncML DTD code page) is to be used. | 01 | Corresponds to the </Data> tag. |
Device Information DTD In the SyncML Synchronization Protocol, device- and service-specific information are presented within a document formatted according to the Device Information (DevInf) DTD. This document includes the following characteristics related to a device or a service: Hardware characteristics, e.g., the model of a device Software characteristics, e.g., the version of the Client software used Datastore capabilities, e.g., supported content formats Synchronization capabilities, e.g., supported sync types Device manufacturer specific information
The DevInf documents are needed for the exchange of the device and service capabilities in the Initialization phase of the Synchronization Protocol. This exchange commonly happens only once for a Client-Server pair. If necessary, the Client or the Server can request to repeat the exchange. The transfer of the document is similar in nature to any payload data transferred between the Client and the Server. That is, the DevInf document is carried as a MIME object within a Data element type. There are two MIME content types for the Device Information document. The MIME content type of application/vnd.syncml-devinf+xml identifies the XML representation and application/vnd.syncml-devinf+wbxml identifies the WBXML binary representation. The utilization of the Device Information DTD, in practice, highly depends on the implementations themselves. Clients typically use the device information only to determine a media format and/or datastore names. Clients can even ignore the device information of a Server. In general, Server implementations substantially utilize the device information functionality. Different Server implementations may, however, use the device information quite differently. Some Servers carefully check what is supported in a Client and behave accordingly. For instance, if they realize that a Client does not support some properties of a content type, they can take that into account when synchronizing with that Client. The synchronization services can therefore be dynamically customized for devices of different kinds. DevInf element types The element types of the DevInf DTD can be divided into four different categories. The element types can be either related to general characteristics, datastore properties, synchronization capabilities, or miscellaneous purposes. Table 7-3 shows the categories and element types that belong to them. Table 7-3. DevInf Element Types within CategoriesCategory | Element Types |
|---|
Common Information | DevID, DevTyp, FwV, HwV, Man, Mod, OEM, SwV, and UTC | Content Type Properties | CTCap, CTType, DataStore, DataType, DisplayName, DSMem, MaxID, MaxMem, ParamName, PropName, Rx, Rx-Pref, SharedMem, Size, SourceRef, Tx, Tx-Pref, ValEnum, and VerCT | Sync Capabilities | MaxGUIDSize, SupportLargeObjs, SupportNumberOfChanges, SyncCap, SyncType | Miscellaneous | Ext, DevInf, Xnam, Xval, and VerDTD |
The element types belonging to the Common Information category mostly specify information that can be beneficially used to associate out-of-band characteristics with a device. For instance, there may be special characteristics related to a specific version of a device model. The DevID element type specifies the identifier of the source device. For instance, this may be the serial number of the device. The model of a device is specified within Mod. If the OEM (Original Equipment Manufacturer) is different than the actual manufacturer (specified with Man), it can also be specified. The type of the device, e.g. a phone, is indicated in DevTyp. Common Information element types also carry versioning information related to firmware, hardware, and software. Below is an example, showing how a Nokia® 9210 Communicator has used some of these element types. <Man>NOKIA</Man> <Mod>9210</Mod> <SwV>256</SwV> <HwV>301</HwV> <DevID>IMEI:004400101290920</DevID> <DevTyp>phone</DevTyp> In version 1.1 of the Device Information DTD specification, the SyncML Initiative added the UTC element type for the Client to specify whether it supports time zones for its applications or not. By including the UTC (Coordinated Universal Time) flag in the device information, the Client can specify that it supports time zones, thus telling the Server to send all application data in relation to the UTC time zone. The Device Information specification requires the DevID and DevTyp element types to be mandatory. The Server must also be able to receive and process the UTC element type. The other element types are optional. The optional element types vary in their usage, and are not widely used. The Content Type Properties category and its element types play a very central role in interoperability and the end-user experience, while synchronizing different contents between a Client and a Server. These element types carry the following information: Supported content types in the form of MIME types Supported receivable and transferable content types for each datastore User-displayable name for each datastore Maximum storable memory capabilities for each datastore Supported properties of each supported content type (i.e. MIME type)
The Content Type Properties element types specify a generic way to represent the supported content characteristic. In other words, they specify which features or fields of a MIME type are supported. The representation of the supported properties can be done in an interoperable way for any MIME type, if the MIME type only needs to be identified. If content type properties and acceptable values and parameter names of the properties need to be specified for the MIME type, they need to be defined in addition to the MIME type itself. The SyncML MetInf specification defines these for MIME types used by calendars, todos, contacts, and memo applications. More about the synchronized content types is discussed in Chapter 11. There are optional and mandatory element types within the Content Type Properties category. The Client and the Server need to be able to negotiate which content types are supported, which are transferable and receivable, and which properties of the supported content types are actually implemented. The display name and memory information are optional. The element types of the Sync Capabilities category indicate three types of information. First, the supported Sync Types (from the Synchronization Protocol) are specified inside the SyncCap and SyncTyp element types. For instance, if an entity supports the Sync Types Two-way sync and Slow sync, the support would be indicated in the following way: <SyncCap> <SyncType>1</SyncType> <SyncType>2</SyncType> </SyncCap> Second, the MaxGUIDSize element type of the Sync Capabilities category specifies the maximum size (in bytes) of unique identifiers of data items for a given datastore. This element type is only sent by SyncML Clients. In practice, MaxGUIDSize limits the size of the identifiers used by the Server when sending Add operations to a Client. Naturally, the Server may internally use longer identifiers for data items, but when adding items to a Client the Server may have to use temporary identifiers in order to limit the size of identifiers. The 1.1 version of the SyncML specification introduced features for transferring large objects and for indicating how many changes have been made after a previous synchronization time. These features are optional. Thus, there needs to be a way to indicate whether these features are implemented or not. The SupportLargeObjs and SupportNumberOfChanges element types provide this functionality. It is clear that the element types of the Sync Capabilities category are crucial to enabling synchronization between a Client and a Server. Therefore, all these element types need to be implemented if they are applicable. The last category of the DevInf element types, the Miscellaneous category, is dedicated to specifying the following: Root element type of the DevInf DTD Used version of the DevInf DTD Supported nonstandard and experimental extensions
The root and version element types are obviously mandatory for all implementations. The element types used to indicate nonstandard and experimental extensions are only used for proprietary or experimental purposes and the implementations can choose not to support them. |
