This document highlights some of the new features and improvements which can be found in version 2 of the protocol.
Previously the log on procedure utilised several operations to authenticate the user and exchange information about the reading system and service attributes.
This lengthy handshake has been simplified to a single log on operation which combines the authentication and attributes in a single call, resulting in improved performance especially on mobile networks.
The new log on procedure is as a result also much easier to implement in new services and reading systems.
It is also possible as a result for services to present information (IE specific bookshelf items or dynamic menus) based on the particular kind of reading system authenticating with the service.
A new Service Discovery list maintained by the Daisy Consortium has been introduced; this list will allow users to “discover” available DODP Services based on their Geolocation or preferred reading language.
This would also allow independent discovery of services by a user, and act as a centralised list of available libraries in an accessible format.
The Service Discovery list also will allow sharing of information regarding available Reading Systems which support the new protocol and Services, one such information is public encryption keys for secure exchange of information between reading systems and services.
Previously configuring a Reading System to work with a particular service was a lengthy and time consuming process which necessitated either a technician or tech savvy user. Limitations on Reading System UI made it hard for users to enter the needed details, such as Service URL and User Credentials to log on to the service.
Equally, for organisations supplying Reading Systems to the User, the process to configure a Reading System prior to delivery was very time consuming.
By combining the features on the new log on process and Service Discovery, we are now able to automatically configure devices in the field.
This can be done easily by utilising a unique identifier, in most cases a Serial Number, which is then associated with a User account by the service.
Using the encryption keys found in the Service Discovery page, we can securely exchange credentials with a reading system when it’s first powered on.
For organisations distributing Reading Systems this also means they could simply scan the Serial Number bar code and the Reading System would be automatically configured next time is powered up by the user.
Previously the content lists delivered to the Client were separated in 3 ambiguous categories, necessitating 3 calls to build a User’s “Bookshelf”.
We have simplified the operation and removed ambiguity by removing the concepts of “New” “Issued” and “expired”. There is now a single content list which is the entirety of the User’s available content in a single call.
This greatly simplifies the content retrieval process and removes ambiguity which led to different behaviours on different Reading systems and Services; it also improves performance, particularly on Reading Systems connecting over a Mobile Network.
We have also strengthened the amount of information (Metadata) available to the Client when building a bookshelf.
Previously the Client had to call an Operation (previously know and getContentMetadata) for each content item in the users Bookshelf. In this version all the information we have merged the content list and content metadata information into a single operation which passes on all the information needed to build the User’s Bookshelf.
Greater description on the functions of existing Metadata allow for standardised passing of Cover images and Synopsis of a title for a richer UI reading experience.
This enables a much better user experience, particularly in Apps or other GUI based Reading Systems which previously had to rely on non-standard ways to display such information.
Previously the Service was not informed of the action taken on a content item by a Reading System and could therefore not optimise the experience for a particular action.
This also didn’t allow rights management on a title by title level, for example one may wish to protect some content from being copied from a particular device.
The protocol now allows passing metadata about allowed actions on each content item, these include:
- Stream: The content is allowed to be streamed; this provides only content on demand but does not permanently store it on the device.
- Download: This allows unrestricted download of content to the device, the user may transfer the content from the device to external media.
- Download Restricted: Allows download of content only to internal memory of the device, the user is not able to move the content to a different device or media.
- Automatic Download: Gives the reading system a hint to inform the system the service wants it to download this content automatically.
This enables the service to deny an action not permitted by copyright restrictions on a particular item.
Equally this enables the Service to optimise the resources for any given particular action, for example re direct downloads to a different priority server to manage bandwidth.
The new Automatic Download feature would also allow the operation of automated downloaders, allowing Services to push content at off peak hours for traffic management and convenience for the user.
The protocol now allows for a standardised method to deliver fully or partially packaged content, enabling Services to pass a single file containing resources for a simpler content resource list.
This can greatly improve content delivery, particularly over mobile networks, as it can consolidate most of the SMIL and HTML contents into a single file.
This also sets the framework for use of EPUB3, which is packaged as a single file.
The new protocol clarifies the functions of announcements; previously the concepts of High or Low priority announcements were undefined and led to different interpretations across services.
The new system allows the Service to set the polling rate at which the Reading System should pull announcements, enabling for faster delivery for time critical applications.
The protocol also defines the importance of the announcement, for instance, a high priority announcement would stop playback and render an announcement immediately, where a low priority announcement would wait for the Reading System to be idle.
A new feature of the protocol is to manage Terms of Service agreements, enabling a Service to ensure users agree to a ToS prior to consuming content on their services.
Equally this would manage ToS updates cross platform, which would work across dedicated Reading Systems and apps.
The protocol now allows for standard guest accounts to connect to a Service, this can potentially enable users to connect to a Service to explore what content is available on that Service, or even consume content which may not be copyright protected.
The Bookmark system has been greatly simplified, what used to be accomplished by over 9 different operations has now been consolidated into 2 simple operations to update or replace a Bookmark Set.
The Bookmark Set is stored by the Service, enabling users to resume playback from their last point across multiple devices, and also synchronise Bookmarks and Highlights across multiple devices.
The system also allows for offline operation, updating and merging Bookmark Sets next time the device goes online.
The Dynamic Menu system within the protocol has been updated, adding clearer documentation around its features such as standardised search and User history features.
The new system also allows for actions to be performed based on a content item or group of items, which simplifies the use for Apps and more complex UIs.