Expressing RSS in ICE (HTML Document)

   <meta name="Author" content="Laird Popkin">
   <title>RSS in ICE</title>

<h1> RSS in ICE</h1>

<p>This document is a follow-up to the discussion thread on the
xml-dist-app list between Laird Popkin and David Winer.

<p><br>Comparison of RSS and ICE, and proposal on how to merge RSS'
functionality into ICE. Note that purely duplicating RSS' functionality
spelled in terms of ICE may not be the appropriate means of merging the
standards, but this should at the least serve as an interesting experiment
in comparing the protocols. In addition, the comparison to RSS reminds me
of one of ICE's original requirements, to allow a syndicator that simply
delivers static files to be a useful, valuable subset of ICE's
functionality. This scenario has not been at the top of the ICE AG's
priority list, so this exercise serves as a good reminder to the ICE AG,
at the very least. The widespread adoption of RSS by low-end syndicators
to distribute promotional links should serve as a clear indicator of the
importance of this scenario in the world of syndication.

<br>This document is written in HTML, but aside from a table and some
examples wrapped in &lt;pre> tags this document is formatted to be fairly
readible as plain text. If this causes real problems for any readers, i
can attempt to convert the table to plain text.

<h2> Comparison</h2>

A brief comparison of the goals and functionality of RSS and ICE.

<h3> RSS</h3>

RSS is an evolution of CDF intended to allow web sites to easily broadcast
links to web pages in order to promote traffic to the web site. It was
originally intended to enable subscription to web "channels" for offline
browsing, but has proven valuable as a simple means of exchanging web
content between web sites. Thus, it provides for a relatively simple set
of functionality that is easily implementable:


<li> delivery only of web pages</li>

<li> support of pull delivery of content</li>

<li> content delivered is linked to, not transported to the subscriber for

<li> simple scheduling</li>

<li> all content is identical for all subscribers</li>

<li> no access control</li> 


<h3> ICE</h3>

ICE is intended to support the full range of content sydication. It has a
number of commercial implementations, generally targeted at businesses
that wish to distribute or aggregate large volumes of content with
numerous business partners. Thus, it offers a range of options including:


<li> delivery of arbitrary content types, including web pages</li>

<li> support of both push and pull delivery of content</li>

<li> access control and customization of content</li>

<li> Both "full update" and "incremental update" supported, with atomicity
of updates, recovery mechanisms for error conditions, etc.</li>

<li> content delivered in-line or by reference</li>

<li> confirmation of delivery</li>

<li> auditing of ICE operations</li>

<li> rich scheduling of ICE delivery</li>

<li> meta-data relating to intellectual property, usage rights, copyright,

<li> automated negotiation of delivery and other parameters</li>

<li> extensible</li>

<li> syndication discovery protocol</li>


Note that while ICE offers these capabilities, it is not required that
they be used for any particular syndication. Beyond this, it appears
valuable to formally modify ICE and to define a subset of ICE that could
be implemented in order to provide comparable functionality to RSS, with
comparable simplicity of implementation. One can also imagine extending
RSS to incorporate ICE's functionality as a comparable phrasing of this

<p>Recognizing that there is significant value in a single syndication
standard that encompasses the full range of online content syndication, I
propose a "straw man" proposal for expressing RSS functionality within
ICE, inclugin modifications to the ICE protocol to support identical
behavior as RSS. I do not expect that this proposal would be adopted "as
is,"  but would like to use it as a starting point for an exploration of
unifying the two standards.


<h2> Mapping RSS into ICE</h2>

<p><br>I first explore mapping the RSS XML elements into ICE. I based the
RSS on the <a href="
quickstart.html#rsssyntax">My Netscape Network Help</a> reference
document, and the ICE on the 1.1 draft currently in the ICE AG's egroups

<table BORDER WIDTH="100%" >
<tr BGCOLOR="#999999">



<td>&lt;?xml version="1.0"?>&nbsp;</td>

<td>&lt;?xml version="1.0"?>&nbsp;</td>

<td>standard XML label</td>

<td>&lt;!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"

<td>&lt;!DOCTYPE ice-payload
<br>SYSTEM "ice11.dtd"></td>

<td>RSS mandates single, shared DTD.</td>

<td>&lt;rss version="0.91" encoding= "ISO_8859-1">&nbsp;</td>

<td>&lt;ice payload ice.version="1.1" payload-id="1"></td>

<td>one top level element, required</td>



<td>one required</td>



<td>one required</td>

<td>&lt;description>Your source for Mozilla news, advocacy, interviews,
and more!&lt;/description></td>

<td>description="Your source for Mozilla news, advocacy, interviews, 

<td>one required</td>


<td>ice-catalog's url attribute</td>

<td>one required</td>

<td>&lt;language>[ language code here ]&lt;/language></td>

<td>ice-catalog's xml:lang attribute, or
<br>ice-package's xml:lang attribute</td>

<td>one required</td>

<td>&lt;rating>[ PICS rating here ]&lt;/rating></td>

<td>add &lt;rating> to ice-offer</td>

<td>one optional</td>

<td>&lt;copyright>Copyright 1999, Mozillazine.&lt;/copyright></td>

<td>ice-offer's rights-holder="Copyright 1999, MozillaZine,"</td>

<td>one optional, ignored by NetCenter</td>

<td>&lt;pubDate>Thu, 08 Jul 1999 07:00:00 GMT&lt;/pubDate></td>

<td>ice-package attribute activation="1999-07-08T07:00:00"</td>

<td>one optional, ignored by NetCenter</td>

<td>&lt;lastBuildDate>Thu, 08 Jul 1999 16:20:26 GMT&lt;/lastBuildDate><

<td>payload attribute timestamp="1999-7-08T16:20:26"</td>

<td>one optional, ignored by NetCenter</td>


<td>&lt;ice-business-terms xml:lang="en-us" type="licensing" url=

<td>one optional, ignored by NetCenter</td>


<td>&lt;ice-contact description="Managing Editor" xml:lang="en-us" 

<td>one optional, ignored by NetCenter</td>


<td>&lt;ice-contact description="Webmaster" xml:lang="en-us" name=

<td>one optional, ignored by NetCenter</td>


<td>add image-ref to ice-offer, based on ice-item-ref</td>

<td>one optional</td>

<td>&nbsp;&nbsp; &lt;title>MozillaZine&lt;/title></td>

<td>&lt;ice-offer product-name="MozillaZine"
<br>or image-ref's attribute name="MozillaZine"</td>

<td>one required if &lt;image></td>

<td>&nbsp;&nbsp; &lt;url>

<td>image-ref's attribute url="

<td>one required if &lt;image></td>

<td>&nbsp;&nbsp; &lt;link>;/link></td>

<td>add url to ice-offer</td>

<td>one optional if &lt;image></td>

<td>&nbsp;&nbsp; &lt;width>[ numeric value here ]&lt;/width></td>

<td>image-ref's attribute width="[ numeric value here ]"</td>

<td>one optional if &lt;image></td>

<td>&nbsp;&nbsp; &lt;height>[ numeric value here ]&lt;/height></td>

<td>image-ref's attribute height="[ numeric value here ]"</td>

<td>one optional if &lt;image></td>

<td>&nbsp;&nbsp; &lt;description>Articles, discussions, builds, and 

<td>ice-offer's attribute description="Articles, discussions, builds, 

<td>one optional if &lt;image></td>



<td>0-15 allowed</td>

<td>&nbsp;&nbsp; &lt;title>Java2 in Navigator 5?&lt;/title></td>

<td>name="Java2 in Navigator 5?"</td>

<td>one required per &lt;item></td>

<td>&nbsp;&nbsp; &lt;link>


<td>one required per &lt;item></td>

<td>&nbsp;&nbsp; &lt;description>Will Java2 be an integrated part of 
5? Read more about it in this discussion...&lt;/description>&nbsp;</td>

<td>&lt;ice-item-ref>&lt;ice-access-control description="Will Java2 be
an integrated part of Navigator 5? Read more about it in this 

<td>one optional per &lt;item></td>


<td>add &lt;textinput> as defined by RSS to ice-offer.</td>

<td>one optional, implemented by HTTP FORM GET</td>

<td>&nbsp;&nbsp; &lt;title>Send&lt;/title></td>


<td>one required if &lt;textinput></td>

<td>&nbsp;&nbsp; &lt;description>Comments about MozillaZine?&lt;/


<td>one required if &lt;textinput></td>

<td>&nbsp;&nbsp; &lt;name>[ value of name= attribute of input tag here


<td>one required if &lt;textinput></td>

<td>&nbsp;&nbsp; &lt;link>


<td>one required if &lt;textinput></td>


<td>ice-offer's ice-delivery-policy's ice-delivery-rule</td>

<td>up to 24, optional, ignored by NetCenter</td>

<td>&nbsp;&nbsp; &lt;hour>7&lt;/hour></td>


<td>optional, ignored by NetCenter</td>



<td>optional, ignored by NetCenter</td>

<td>&nbsp;&nbsp; &lt;days>Monday&lt;/days></td>


<td>up to 7, required if &lt;skipDays></td>

<caption ALIGN=BOTTOM>&nbsp;</caption>

<h2> Example messages</h2>

The following is an example RSS message and a comparable ICE message.  
Note that many RSS elements mapped above (based on the RSS specification)  
were not used in the RSS messages that I have seen in production, and are
thus not reflected below. I believe that this makes the following messages
fairly realistic reflections of how typical RSS syndications can be
encoded. <br>

<hr WIDTH="100%">

<center><h3>RSS Message</h3></center>

<pre>&lt;?xml version="1.0"?></pre>

<pre>&nbsp; &lt;!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD 
RSS 0.91//EN"</pre>

nbsp;&nbsp;&nbsp; "

<pre>&nbsp; &lt;rss version="0.91"></pre>

<pre>&nbsp;&nbsp;&nbsp; &lt;channel></pre>


<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>MozillaZine&lt;/title></

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;description>Your source for 
Mozilla news, advocacy,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interviews, builds, and 
more! &lt;/description></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;language>en-us&lt;/language></

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rating>(PICS-1.1 "http://"</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; l gen true comment 
"RSACi North America Server"</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for "http://" on "1996.04.16T08:15-0500"</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r (n 0 s 0 v 0 l 0))&

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;image></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>MozillaZine&

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;url>http://;/url></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;width>88&lt;/width>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;height>31&lt;/

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;description>
Articles, discussions, builds, and more...&lt;/description></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/image></pre>


<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>Java2 in 
Navigator 5?&lt;/title></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;description>Will 
Java2 be an integrated part of Navigator 5?</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Read more about it in 
this discussion...&lt;/description></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/item></pre>


<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>Communicator 
4.61 Out&lt;/title></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;description>The 
latest version of Communicator is now</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; available. It includes 
security enhancements</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and various bug fixes.&

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/item></pre>


<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>Mozilla 
Dispenses with Old,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proprietary DOM&lt;/

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/item></pre>


<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>The Animation 
Contest is Now Closed!&lt;/title></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/item></pre>


<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;textinput></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title>Send&lt;/

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;description>
Comments about MozillaZine?&lt;/description></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;name>responseText&

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link>http://;/link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/textinput></pre>

<pre>&nbsp;&nbsp;&nbsp; &lt;/channel></pre>


<pre>&nbsp; &lt;/rss></pre>

<hr WIDTH="100%">

<center><h3>ICE Message</h3></center>

<pre>&lt;?xml version="1.0"?></pre>

<pre>&lt;!DOCTYPE ice-payload SYSTEM "ice11.dtd"></pre>

<pre>&lt;ice-payload ice.version="1.1" payload-id="1" timestamp="1999-

<pre>&nbsp; &lt;ice-header></pre>

<pre>&nbsp;&nbsp;&nbsp; &lt;ice-sender name="MozillaZine" role=
"syndicator" sender-id="[ GUID ]" location="

<pre>&nbsp;&nbsp;&nbsp; &lt;ice-user-agent>Mod::ICE-RSS/0.1&lt;/user-
agent> &lt;!-- not required, but could be useful for support --></pre>

<pre>&nbsp; &lt;/ice-header></pre>

<pre>&nbsp; &lt;ice-response response-id="1"></pre>

<pre>&nbsp;&nbsp;&nbsp; &lt;ice-code numeric="200" phrase="OK">&lt;/

<pre>&nbsp;&nbsp;&nbsp; &lt;ice-package fullupdate="true" old-state=
"ICE-ANY" new-state="1999-7-08T16:20:26" package-id="1" subscription-

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-catalog name="MozillaZine's 
ICE/RSS server" url="" xml:lang="en-us"></

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-image-link 
image-url="" url=

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; height="88" 
width="31" description="Articles, discussions, builds, and more..."></

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-image-link></

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-offer name=
"MozillaZine" description="Your source for Mozilla news, advocacy, 
interviews, builds, and more!"></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-

nbsp;&nbsp; &lt;ice-delivery-rule mode="get" url="http://"/></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rating>
(PICS-1.1 ""</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; l gen true 
comment "RSACi North America Server"</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for "http:/
/" on "1996.04.16T08:15-0500"</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r (n 0 s 0 
v 0 l 0))&lt;/rating></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &
lt;textinput> &lt;!-- straight from RSS --></pre>


&lt;description>Comments about MozillaZine?&lt;/description></pre>



<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-offer></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-catalog></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-item-link name="Java2 in 
Navigator 5?" url="

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; description="Will Java2 
be an integrated part of Navigator 5? Read more about it in this 

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-item-link name=
"Communicator 4.61 Out" url="

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; description="The latest 
version of Communicator is now available. It includes security 
enhancements and various bug fixes."></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-item-link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-item-link name="Mozilla 
Dispenses with Old, Proprietary DOM" url="

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-item-link></pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ice-item-link name="The 
Animation Contest is Now Closed!" url="

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/ice-item-link></pre>

<pre>&nbsp;&nbsp;&nbsp; &lt;/ice-package></pre>

<pre>&nbsp; &lt;/ice-response></pre>


<hr WIDTH="100%">


<ul> <li> The ICE encoding tends towards fewer elements with attributes,
whereas the RSS encoding consists almost entirely of elements with no
attributes. Encoding with attributes rather than nested elements is
substantially more efficient, both in terms of code complexity and
processing time, due to the simpler data structures (DOM) or collection of
relevant data into events (SAX). May want to re-express the textinput
structure as attributes rather than nested elements for consistency with
the rest of ICE.</li>

<li> I am assuming that the ice-payload will typically be delivered as a
static file that is generated periodically, either on a schedule or
triggered by content changes. Thus, the timestamps would be the timestamp
of the last time the file was written, the payload id would simple
increment, and so on. Of course, if the file is generated dynamically
(i.e. the GET is to a cgi or Servlet) the entire process could be data
driven. The subscriber shouldn't care, but we should make sure that the
trivial, static file option is straightforward to implement.</li>

<li> ICE uses a specific form of ISO8601 time, date and period
specification. Since ICE specifies that (for simplicity of implementation)
all periods are specified in seconds, rather than the broad range of units
allowed by ISO8601, the RSS "hours" scheduling is rather cryptic looking
(1 hour = a 3600 second period, or P3600S in ISO8601). We may want to
consider adding hours to the allowable units, allowing the more reasonable
P1H for one hour, etc. This is added code complexity, but probably more
human readable. Unlike typical ICE scenarios, involving content management
systems, low-end ICE-RSS syndicators may, in fact, hand-author this file
for their site, in which case simplicity of expression is valuable even at
the cost of somewhat more complex implementation on the receiving side.
It's worth discussing, at any rate.</li>

<li> Similarly, for full update packages, old-state is somewhat redundant,
since it must always have the value of "ICE-ANY". I would suggest that we
may want to change is attribute to #IMPLIED, defaulting to "ICE-ANY", in
order to make the expression of full updates more compact.</li>

<li> There are some relationships in RSS that aren't completely clear to
me. For example, is &lt;image> intended to be an image that refers to the
syndicator as a whole, or to the particular channel being transmitted, or
is it simple another kind of item? I interpreted it as applying to the
syndicator as a whole, by encoding it in the ice-catalog (i.e. where other
contact information would go).</li>

<li> Encoded the ice-package in an ice-response. In principle the
HTTP&nbsp; GET of the URL can be treated as if it were an ice-request of
ice-get-package with no subscriber ID. As there is no protocol-level
communication channel from the subscriber to the syndicator, the
ice-package generated in a GET mode subscription cannot request
confirmation from the subscriber.</li>

<li> RSS doesn't have any concept of a failure code, so to duplicate RSS
the ice-response's ice-code would always be 200/OK.</li>

<h2> Changes to ICE</h2>

The key addition to the ICE protocol is an extremely limited content
deliver mode, "GET", in which the only communication between the
syndicator and subscriber consists of the subscriber issuing a GET of a
provided URL, and receiving the requested content. In addition, there are
a small number of DTD changes that would be required to fully express RSS'
functionality in ICE. This delivery mode utilizes an extremely minimal
subset of ICE's functionality, but the extreme ease of implementation, and
the prospect of unifying two divergent standards for content syndication
to the benefit of all concerned, make this an extremely valuable scenario
to explore. The changes to the ICE protocol are generally consistent with
ICE's design philosophy, and of general use to a variety of syndication 

<p>This scenario involves making the following changes to ICE:


<li> Add PICS rating to offer. PICS ratings should be added to ice-offer.
I simply adopted the RSS &lt;rating> tag.</li>

<li> Add ice-item-link, a duplicate of ice-item-ref, with the added
attribute description, and the semantic that the asset is to be linked to
rather than retrieved and utilized locally. Linked assets are appropriate
if the syndicator wishes to take advantage of site-specific functionalty
or to control, track or benefit from the actual delivery of the content.  
Assets encoded as ice-item-link must be served on a persistent server
accessible at the provided URL for use by the general public.</li>

<li> Add ice-image-link to the contents of ice-catalog and ice-package.
For ice-offer it would be for display to users in selecting between
offers. For ice-package it would be an alternative to ice-item-link that
has additional attributes, image-url, height, and width, relevant to image

<li> Consider adding ice-image and ice-image-ref to ICE, as the height and
width attributes may be useful to subscribers for images that are encoded
inline or by reference.</li>

<li> Add url to ice-offer, to provide a link to a web page that describes
the offer more fully than can be embedded in the ice-offer. This is
valuable to any ICE implementation.</li>

<li> Add RSS' textinput mechanism to ice-offer. ICE does not have this
concept. Add this as an optional element contained within ice-offer.
Again, this is probably generally useful to ICE syndications in any
delivery mode.< /li>

<li> Add a delivery mechanism, get, to the delivery modes, in addition to
the existing push and pull delivery modes. Get delivery would allow the
subscriber to do a simpe HTTP GET of a provided URL in order to retrieve
updates. As this means that the syndicator has no knowledge of the
subscriber's identity or state, GET delivery is only supported for full
updates of content that is not customized to particular subscribers.</li>

<li>The ICE protocol does not require the negotiation process. Therefore,
a subscription with get delivery could be initiated simply by having the
syndicator publicize the URL from which the ice-payload can be retrieved.
Of course, the standard ICE subscription discovery and negotiation
mechanism can be followed for get mode subscriptions.</li>

<li>In addition, for GET subscriptions, in order to simplify
implementation, the only allowable elements would be: ice-payload,
ice-header, ice-sender, ice-response, ice-package, ice-image-link and
ice-item-link. This would allow syndicators and subscribers that support
only the get mode of delivery to have an extremely simple

<li>Since GET subscriptions are anonymous, subscription-id for such 
subscriptions should be an empty string.</li>

<li>Finally, in order to model RSS's bundling of subscription information 
into the file containing the content, I would propose adding the
ice-catalog structure, containing only the single ice-subscription
relevant to the ice-package, as an an optional component within the
ice-package. While syndicators could provide the full ICE level of detail
for themselves (contact information, etc.) the receiver can feel free to
ignore all attributes not mapped above.</li>

<h2>Open Issues</h2>
There are a number of issues where it may make sense to adopt more of
ICE's functionality even into this "simplified" model of ICE modeled on
RSS. For example:
There may be value in supporting regular ICE inline content encoding 
(ice-item) and reference (ice-item-ref, type="retrieve") for GET
subscriptions. As this would be new functionality for RSS, this option is
not explored in this document, but it may be appropriate for a fuller
merging of the protocols.</li>

<li>Descriptions, names, etc., are encoded as plain text attributes in the 
XML. We may want to consider encoding them using the ice-text 
structure, which would allow alternate representations in varions
languages and character encodings. RSS doesn't have alternate
encodings, so I stuck to the simpler string representation for
simplicity in modeling RSS.</li>

<li>There are a number of RSS features that are specified but not 
implemented by Netcenter. If there are specified RSS features are
generally not implemented by RSS users, it may be preferable not to add
those features to ICE.</li>

<li>RSS doesn't have the concept of failure status. If RSS "files" are 
dynamically built, many of the ICE error codes having to do with
operational availability, permanent redirection, etc., are probably

<li>One can also easily imagine it being useful to send in-band 
notification (ice-notify) to subscribers.</li>

Received on Wednesday, 31 May 2000 04:11:50 UTC