The general environment for Atom is assumed to be PC-type clients. A PC client is typically wall-powered and has a high-bandwidth network connection. Battery powered laptop PCs may run for a few hours but it it is generally assumed the laptop can be easily recharged at any power outlet. The situation for *portable* devices is quite different. Portable devices are battery powered and typically have slow or costly network connections. Portable devices are typically left on in a stand-by mode and are expected to run for days without recharging. Recharging is not always convenient for portable devices (such as cell phones) because the charging cables/adapters are typically not personally carried. The polling model for Atom is not well optimized for devices with limited power and limited network bandwidth.

The current polling model suggests that at some regular time interval, the client polls subscribed feeds. For a portable device, at some regular interval the device needs to come out of “stand by” and fully power up. The portable device would then need to transmit/receive to establish an IP connection with a wireless service. At this point, the Atom servers may be contacted; meanwhile, the battery is draining. Even if conditional GETs and incremental HTTP are used, the battery is still draining by setting up the IP connection and making the requests to the servers (even if nothing is returned). Another issue is that each server must be contacted without any way of knowing a priori if it has anything new.




Portable devices are becoming common application platforms. It is desireable to make Atom friendly to deployment on portable platforms.


The proposal is to include an element in the Atom head similar to the RSS 2.0 “TTL” (time to live) element [1]. The intent of this element in the RSS 2.0 spec is to give the client some idea of how long the most recently loaded feed is valid before it becomes stale and needs to be reloaded. If an element similar to TTL is included in an Atom head element, the client could determine how long it would need to wait before doing the next update. The client then contacts servers for feeds that are stale. A simple example is <ttl>120</ttl> (time units of minutes) indicating the server will not generate new information for at least two hours and thus the client does not need to contact the server for at least two hours.

Providing a TTL-like element has the following virtues for portable devices: - Allows a portable device to have some indication of when it actually needs to do an update. - Allows the portable device to contact only servers that have stale feeds. - Allows the client to determine how many feeds need updating and be able to estimate how much power or time the update may take (for example, an update may be deferred if the battery is running low).


* Requires adding an additional element in the <head> such as <ttl>120</ttl>. * Impact on inserting this value for static and dynamic feed generators needs to be evaluated.