We generally rely on the RSS 2.0 Specifications as published by the Harvard Law School for guidelines on how we expect the feeds we interact with to be written.

It's also important to note that some of the fields that are defined as optional by the specs, are actually very important to the way that we process the content.

For example, <pubDate> is defined as an optional element in the RSS spec.  But feeds that do not provide pubdates are highly susceptible to a number of problems.  We always give a pubdate when serving post content from our system, so if the publisher does not provide one, we assign it one equal to the date and time that we pulled it into our system.   If a feed with many old posts but no pubdates is introduced into our system for the first time today, we will mark all posts as having today as their pubdate. This can cause some unwanted behavior in widgets, readers, client applications, or API based applications.  Also, if we cannot read from your feed for whatever reason (your feed has some malformed XML, or your server is down) for a period of time spanning several new post publications, the same type of problem will occur the next time we successfully find the new posts  and pubdates are not supplied.

Note that badly formatted pubdates can be just as bad as not having a pubdate. We try very hard to parse pubdates, but if we can't parse your pubdate we will ignore it. To be safe you should try to conform to a published standard such as ISO 8601.

Also be sure your pubdate includes a timezone. If it doesn't include a timezone we will assume it's in the US Mountain Timezone.

Another essential element for us is the <guid>. This is also defined as optional, but again, non-use or improper use opens your feed to a number of unwanted behaviors.  The most likely of which is the introduction of "duplicate" posts whenever edits are made (see "Editing a post item in an RSS feed" for more on this).