From Todd Larason:
a "/update?session-id=foo&revision-number=bar" request returns immediately if the server revision-number doesn't equal 'bar'. If it does equal 'bar', then there's no response until the server revision-number increases. This is a little fragile -- if you kill a connection, it's not going to work again for that session-id; you need to log out and log back in.
using 'delta' with /update is legal but seems useless; after the initial /update revision-number=1, iTunes uses both revision-number and delta, with both set to the same number.
With other requests, delta is more useful -- it lets you get updates rather than downloading the whole database again.
You pass revision-number=R1 and delta=R2, where R1 is what you believe the current database revision number to be, and R2 being the revision number you already have information for. If R1 is out of date, you'll get back a dmap.updateresponse instead, like you would if delta weren't there.
If R1 is valid, you'll get back partial results.
In general dmap.specifiedtotalcount is still the number of items in the set you've asked about; dmap.returncount is now the number of items being returned to you, which will likely be lower.
Item is included if they're changed in one of the obvious ways; a song being played counts as a change, but being added to a playlist doesn't. If items have been deleted, besides the 'dmap.listing' list with dmap.listingitem items, there's a dmap.deletedidlisting list with dmap.itemid members with, reaosnably enough, the IDs of the deleted items.
It seems that when you make a request with item 'delta=foo', you're saying you're no longer interested in deltas against earlier revisions. You can still ask for them, and you won't get an error, but the results don't always seem to be accurate.