> One, allow a program that possess a GUID for an *item* to be able
> to
> return to the item's source and request a "more complete" XML
> represenation of the item. This would let programs using the RSS
> find out more about an item. This would let the feed remain
> reasonably compact. It'd also allow a site to deliver
> considerably
> more complete data, but only when requested. This could save a
> fair
> amount of CPU as many items probably won't ever get requested.

I think this is a good idea, as long as the "more complete" XML is
still of the RSS/RDF variety. That is, the compact version would be
of the .9x variety, and the complete version would be of the 1.0
variety (with modules etc). This could apply to individual items of
a feed, or the entire feed itself.

> Two, allow a client program to 'carry along' some source
> information
> as an item moves through site to site. Many item do have a source
> and are simple echoed from one feed to another. Yes, some feeds
> do
> add more information on top of an item.

This should be cause for a new GUID. You mentioned in another place
(forget where exactly) the idea of a "path." I looked into the
pointers you provided and agree that it's a good idea. If I modify
an item I have consumed and then redistribute it (with modification)
it should be given a new GUID, and have another element added to the
path. (perhaps the path ought be the string of GUIDs, new to old)