Content Syndication Using ICE

Content Syndication Using ICE

RSS is a simple mechanism for enabling the syndication of lightweight content. RSS was designed to be simple to use and inexpensive to implement. Although RSS has proven quite useful for the syndication of free content, RSS remains limited in its ability to enforce business rules in the content syndication environment. To fill this role, a second, more robust syndication protocol, Information and Content Exchange (ICE), was devel-oped by industry content providers and software vendors. ICE was developed to auto-mate the negotiation of subscription characteristics and to address the need to automate scheduled, reliable, secure redistribution of any content for publishers and for non-com-mercial content providers.

The History of ICE

On October 27, 1998, a press summit held in San Francisco announced the completion of a new XML-based Web protocol called ICE. On October 28, W3C acknowledged the submission of a Note on ICE. Today, the ICE protocol stands at version 1.1, and work on a Web services version of ICE—ICE 2.0—has begun. ICE was initially designed to meet the syndication requirements of Web content providers of all kinds. Today, ICE is impor-tant to anyone who wants to distribute information on the Web according to controlled business rules. ICE has been incorporated into many products, including Vignette, Kinecta, Oracle, Interwoven, 3Path, HP Bluestone, and Active Data Exchange.

ICE provides support for the syndication process. The theory behind ICE is that all online businesses have a syndication problem. Here, syndication is defined in a much broader sense than just the distribution of published content. Certainly publishers want a standard way to establish a reliable syndication business process. However, the truth is that all business partners need a reliable and accountable mechanism to exchange infor-mation on a routine basis. What publishers as well as those involved in e-business must do is establish online, networked information-based partnerships. Today, this process is often ad hoc, fragile, error prone, and expensive. This cannot prevail as the predominant Web model for syndication.

ICE provides us with a standard model that can be automated to support syndication for all. The importance of adopting a standard interchange mechanism is that it will lower costs of entry by eliminating the requirement to write customized scripts for each busi-ness partner that is added to the value chain. This, in turn, will increase opportunity by enabling a quick, inexpensive, and standard way to add new trading partners. The exis-tence of a standard format for interoperating between business partners is critical.

ICE is not a file format but rather a bidirectional protocol designed specifically to sup-port content dissemination on the Web. New opportunities created by ICE include the following:

   The ability for publishers to generate new revenue streams from existing content

   The ability to lower cost of content exchange among networked trading partners

   The ability to expand distribution of information (increased market share and increased revenue)

   The ability to create Internet Value Networks, not islands of information

ICE Authoring Group

The initial members of the ICE Authoring Group were Web pioneers who recognized that they needed a standard protocol for interoperating. These pioneers included Con O’Connell, Neil Webber, and Brad Husick from Vignette, Laird Popkin from News America Digital Publishing, Rick Levine from Sun Microsystems, Doug Bayer from Microsoft Corporation, Jay Brodsky from Chicago Tribune Media Services, Bruce Hunt of Adobe Systems, Andy Werth from CNET, John Petrone from Preview Travel, Gord Larose from ChannelWare, and Phil Gibson from National Semi-Conductor. The compa-nies that developed ICE were evenly split between software vendors and users of tech-nology, ensuring that it was a standard that met real user requirements. ICE is therefore known as a user-driven technology standard. The ICE Authoring Group and all ICE activities are hosted by IDEAlliance, the International Digital Enterprise Alliance. IDEAlliance provides administrative support for the group and plays a major role in helping to promote the adoption of the standard at conferences and summits.

You can learn more about ICE at its Web site, http://www.icestandard.org.

The ICE Syndication Model

The ICE syndication model differs from the RSS syndication model because RSS enables content providers to make their content free for use across the Web by anyone. However, ICE is specifically designed to enable the managed, reliable, scheduled deliv-ery of content in a business environment. RSS assumes that those using the content may be unknown to the content provider. ICE, on the other hand, assumes that a business rela-tionship has been established before ICE transactions begin. The business agreement can involve personal discussions, legal review, and contracts, just as any business agreement does. ICE transactions begin only after the business agreement has been established.

ICE Terminology

Before we begin to consider a step-by-step example to illustrate the ICE syndication model, it will be helpful to review a few definitions:

   Syndicator. A content provider or aggregator. A content distributor.

   Subscriber. A content consumer or receiver.

   Subscription. An agreement between a subscriber and a syndicator for the delivery of content according to the delivery policy and other parameters in the agreement.

   Catalog. A listing of ICE offerings. This is the listing of all content being offered for subscriptions and the delivery terms for the content.

   ICE offer. A particular subscription offering found within the ICE catalog.

   Delivery policy. The terms of delivery for ICE content. The delivery policy can include start date, stop date, mode (push or pull), delivery days, delivery times, update mode, and delivery URL.

   Collection. The current content of a subscription.

   ICE package. A delivery instance of commands to update a collection such as the addition of content items.

   ICE payload. The XML document used by ICE to carry protocol information. Examples include requests for packages, catalogs of subscription offers, usage logs, and other management information.

ICE Usage Example

ICE is an XML protocol that defines the business rules and processes needed for reliable content syndication among Web servers. Currently ICE uses HTTP as a transport layer. ICE messages, coded in XML, always come in request/response pairs.

Two parties (Web servers) are involved in ICE transactions. The first is the syndicator. The syndicator is the party that provides content—either its own or content it has aggre-gated from other sources. The second party in ICE transactions is the subscriber. The subscriber is the one who wants data from the syndicator. In ICE, certain messages are reserved for the syndicator. Other messages are reserved for the subscriber—and some messages can be used by either party.

Let’s look at a typical ICE scenario so you can follow the steps in the ICE syndication process. In this scenario, a business relationship is established between the syndicator and the subscriber. This process is done in person or by telephone. The subscriber provides the syndicator with an identifier that will be used as the basis for automated ICE transactions.

The next step is for the subscriber to select subscription content. The subscriber sends a message to request a catalog that lists all content offers using the ice-get-catalog request. Listing 13.8 shows the ice-get-catalog request message in XML.

LISTING 13.8  An ice-get-catalog Request

<?xml  version=”1.0”?>

<!DOCTYPE ice-payload SYSTEM “http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-payload payload-id=”PL-2000-08-24T22:10:33.901-DKennedy-423”

timestamp=”22:10:33,741” ice.version=”1.1”> <ice-header>

<ice-sender sender-id=”4af37b30-2c35-11d2-be4a-204c4f4f5020” name=”D Kennedy “ role=”subscriber”/>

<ice-user-agent>

IceBlock Systems ICE Processor, V7.0 </ice-user-agent>

</ice-header>

<ice-request request-id=”2000-08-24T22:10:33_RQ_DKennedyl_1888”>

<ice-get-catalog/>

</ice-request> </ice-payload>

At this point, the syndicator responds by delivering a catalog to the subscriber. Listing 13.9 shows the ice-response message in XML.

LISTING 13.9  ICE Catalog Response

<?xml  version=”1.0”  ?>

<!DOCTYPE ice-payload SYSTEM “http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-payload payload-id=”PL-2000-08-24T22:10:45-XMLFiles-2761”

timestamp=”22:10:45,321”

location=”xmlfiles.idealliance.org”

ice.version=”1.1”> <ice-header >

<ice-sender sender-id=”4a2180c9-9435-d00f-9317-204d974e3410” name=”IDEAlliance” role=”syndicator”/>

<ice-user-agent>

Northstar Protocols ICE Processor, V17 </ice-user-agent>

</ice-header>

<ice-response response-id=”RSP-2000-07-21T02:03:45-XMLFiles-9876”> <ice-code numeric=”200”

phrase=”OK” message-id=”REQ-2000-07-21T02:02:23-DKennedy-345”/>

</ice-response>

<ice-catalog name=”XML  Files  2001  Newsletters“

url=”http://xmlfiles.idealliance.org/offers/xmlfiles.html”>

<ice-contact  name=”XML  Files“>

For  information  please  contact

Catalog  Offers:  Dianne  Kennedy,  650-555-1212

Technical  Support:  David  Steinhardt,        650-555-1313

</ice-contact>

<ice-offer  product-name=”XMLFiles  2001  Newsletter”

offer-id=”XMLFiles-2001-V1-R1”

subscription-id=”ICE-NEW-SUBSCRIPTION”

expiration-date=”2001-12-30”

quantity=”12”>

<ice-delivery-policy stopdate=”2002-01-01”> <ice-delivery-rule mode=”pull”

max-num-updates=”24” min-num-updates=”12” max-update-interval=”P2678400S” min-update-interval=”P43200S”/>

<!-- max-num-updates is two per month, min-num-updates is 12 per year, max-update-interval is 31 days, min-update-interval is 12 hours -->

</ice-delivery-policy> </ice-offer>

</ice-catalog> </ice-payload>

ICE has functions that will enable the automated negotiations of any ICE offer. Suppose, for example, an offer in the catalog is the content that the subscriber wants, but the deliv-ery policy is not acceptable. The subscriber could use ICE messages to negotiate accept-able delivery parameters.

When the subscriber is satisfied with the offer, acceptance for the offer is sent to the syn-dicator. The syndicator will then verify that it accepts the subscription and provides the subscriber with a subscription ID.

The next step is for the subscriber to request initial subscription content. The subscriber uses ice-get-package with the current-state=”ICE-INITIAL” message (see Listing 13.10). The syndicator will provide the initial content for the subscription according to the delivery policy for the subscription in response to this request.

LISTING 13.10 Example of an ice-get-package Message

<?xml  version=”1.0”?>

<!DOCTYPE ice-payload SYSTEM “http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-payload payload-id=”PL-2000-08-24T22:10:33.901-DKennedy-423”

timestamp=”22:10:33,741” ice.version=”1.1”> <ice-header>

<ice-sender sender-id=”4af37b30-2c35-11d2-be4a-204c4f4f5020” name=”D Kennedy “ role=”subscriber”/>

<ice-user-agent>

IceBlock Systems ICE Processor, V7.0 </ice-user-agent>

</ice-header>

<ice-request request-id=”2000-08-24T22:10:33_RQ_DKennedyl_1888”>

<ice-get-package current-state=”ICE-INITIAL” subscription-id=”1”/>

</ice-request> </ice-payload>

Following the initial delivery of subscription content, new content will be delivered from the syndicator to the subscriber according to the delivery policy of the subscription. The content is contained within the ice-payload as an ice-package made up of one or more ice-items. The ICE message may include any kind of content directly in the message (that is, HTML, database records, XML, graphics, PDF, and so on). Typically, though, the ICE item just sends a URL where the content is made available. The ICE message itself can be thought of as an envelope for content and data about the content delivery. When the ice message delivers content, it is always as an ice-response. You can see this message flow in Figure 13.6.

ICE Error Messages

One of the features of ICE that provides a great business advantage is the reliability of content delivery. The ICE protocol is designed so that every request must have a match-ing response. It is these request/response message pairs that enable us to verify and log the receipt of content. The ICE specification has built in a number of ICE error message codes that specifically support automation of syndication. These codes are used within the ice-code element. Listing 13.11 shows how ice-code is used to indicate an error.

LISTING 13.11 Example of ice-code with Error Indication

<ice-response response-id=”REQ-2000-07-21T02:03:00-DKennedy-1873”> <ice-code numeric=”331”

phrase=”Failure fetching external data” message-id=”REQ-2000-07-21T02:02:23-XMLFiles-2397”>

Unable to obtain content from URL: http://xmlfiles.idealliance.org/xmlfiles/xmlfiles2001.htm

</ice-code> </ice-response>

The following list shows some examples of ICE messages. The protocol has been devel-oped based on use-case scenarios. Error messages are designed from these scenarios. Here’s the list:

   200 – OK. The operation successfully completed.

   201 – Confirmed. The subscriber has successfully processed the package.

   331 – Failure Fetching External Data.

   401 – Incomplete/Cannot Parse. You couldn’t even get the parser started!

   402 – Not Well Formed XML. Your XML tags didn’t balance.

   404 – Broken Link. Content is not available at the specified link.

   405 – Unrecognized Sender. Who are you?

   406 – Unrecognized Subscription. You have to have a valid subscription ID.

   407 – Unrecognized Operation. An operation in the package was not one that you recognized.

   408 – Unrecognized Operation Arguments. The attributes on the element were unknown.

   430 – Not Confirmed. A generic error indicating that the subscriber didn’t complete processing.

   501 – Temporary Responder Error. An “I’m too busy right now to do it” message.

   603 – No More Confirmations To Send. When you’ve confirmed everything, respond with this.

ICE clearly contains many more features and imposes many disciplines on the process of content syndication. Therefore, one may make the false assumption that using ICE is a complex and expensive undertaking. It turns out that there are different levels of ICE implementation and ICE conformance. However, actually setting up minimal ICE imple-mentation is easy for anyone.

Simple ICE Syndication

Very simple ICE implementations can provide a basic ability to syndicate content, just as RSS can. You would make syndicated material available in this way by following these steps:

     Create content that you wish to syndicate. Place it on your Web site so that it will be available. Suppose you put the new issue of XML Files at the following URL:

http://www.idealliance.org/xmlfiles/issue30/default.htm

     Construct the following ICE message that describes the location of the content to be syndicated:

<?xml  version=”1.0”?>

<!DOCTYPE ice-package SYSTEM “http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-package>

<ice-item-ref url=”http://www.idealliance.org/xmlfiles/issue30/default.htm” item-id=”xmlfilesissue30”/>

</ice-package>

3. Now place the ICE package on your Web site, such as http://www.idealliance. org/ice/xmlfiles.ice.

That’s all that is required of the syndicator. If you are the subscriber to content that is posted using this simple ICE mechanism, you have two steps you must follow:

     Obtain the URL for the ICE package on the Web site. You might receive this via e-mail. Alternatively, it might be posted on the home page of the site.

     Parse the ice-item-ref URLs out of the ICE package and either download the content or reference it using the URL.

Full ICE Compliance

If you intend to take advantage of the power of ICE to manage content according to busi-ness rules, you will most likely need the full power of ICE and the full range of ICE messaging at your disposal. This means that you will need to purchase a tool that pro-vides ICE capabilities. Because ICE is a server-to-server messaging protocol, you can’t really “see” ICE. However, you can look for it as a standard protocol supported by Web content-management systems.

The ice-payload is the XML document used by ICE to carry protocol information, or ice messages. The ice-payload is homogenous. This means that an ice-payload can only carry one kind of message. The DTD for ICE, shown in Listing 13.12, shows that the payload may carry one or more responses, one or more requests, but may never mix requests with responses.

LISTING 13.12 The DTD for an ice-payload

<!ELEMENT   ice-payload ( ice-header, ( ice-request+ | ice-response+ | ice-unsolicited-now | ice-unsolicited-request+ | ice-unsolicited-response+) ) >

<!ATTLIST  ice-payload

payload-id  CDATA  #REQUIRED

timestamp   CDATA      #REQUIRED

ice.version  CDATA      #REQUIRED   >

There are many different kinds of ICE requests and ICE responses. The syndicator some-times makes requests and sometimes gives responses. Likewise, the subscriber some-times makes requests and other times makes responses. Do not just assume that the subscriber is the requestor. That is not at all the case!

Here’s a list of the standard ICE requests that are supported within full ICE compliance (as you can see, an automated tool to handle all messaging and track states of syndicated content is a must for full ICE syndication support):

   ice-cancel. Cancels the subscription.

   ice-change-subscription. Changes the subscription.

   ice-code. Passes an ICE message code.

   ice-get-catalog. Requests for the syndicator to request an ICE catalog.

   ice-get-events. Returns an ICE events log.

   ice-get-package. Requests for the syndicator to return an ICE package.

   ice-get-sequence. Returns the current ICE subscription state.

   ice-get-status. Returns the status of the subscription.

   ice-nop. Sends a no operation message. Used for debugging.

   ice-notify. Mechanism for sending a text message.

   ice-offer. The ICE subscription offer sent by Syndicator

   ice-package. The ICE package sent from syndicator to subscriber.

   ice-send-confirmations. Returns confirmation from the subscriber that a pack-

age has been received.

• ice-repair-item. Repairs a subscription collection by replacing missing items.

Enabling Content Management with ICE

ICE is designed to give both syndicators and subscribers the ability to manage their con-tent. In the following simple example, the ice-access element specifies the span of time that the URL will be available. This means the subscriber knows how long the link will last. Also, the syndicator has made a commitment to provide it for a specific length of time. Therefore, the duration of the content is now made explicit, meaning each party can avoid the “404” broken link problem.

In Listing 13.13, you can see how we used ice-access-control to limit who may access the content via login and password. A security notice is printed to indicate that even though we are granting access for syndication, the copyright remains with IDEAlliance.

LISTING 13.13 Using ice-access to Manage Content

<?xml  version=”1.0”?>

<!DOCTYPE ice-package SYSTEM “http://www.icestandard.org/dtds/ICE1_1.dtd”> <ice-package>

<ice-item-ref url=”http://www.idealliance.org/xmlfiles/issue30/default.htm” item-id=”xmlfilesissue30” />

<ice-access>

<ice-access-window starttime=”2001-10-01T08:00:00”

➥ stoptime=”2001-10-31T017:00:00”/>

➥ <ice-access-control control-type=”password” ➥ user=”XMLFiles Subscriber” password=”xmlgo”>

2001 IDEAlliance, Inc. All Rights Reserved. Use of the content in this item reference implies acceptance of the use license at

http://www.idealliance.com/licenses/subscriber.html including honoring all copyrights and trademarks. You agree not to provide others with the

access  control  password  above.</ice-access-control>

</ice-access>

</ice-package>