I read a couple of the posts and there seems to be a little bit of
confusion on what exactly we were intending with that field. We'll
have to figure out a better way in our specification to make it more
clear on what our intention is for that attribute.

Essentially, player != client. Our playerUrl is just a normal web page
that shows the media content in the general sense of syndicated web
content. At this time, it's not a means of driving actual client
applications running on the end user's machine outside of the typical
sense of a web browser.

In discussing the needs with assorted partners, it became clear that
often (even at the time of RSS generation, believe it or not) a
direct link to the actual media content is unknown to them or cannot
be generated. This is because of security protections they have in
place, etc. And often, due to licensing reasons, they are unable to
reveal such links anyway.

Here's a live example of what a playerUrl might be:
http://nbc.com/nbc/Video/?c=The_Apprentice/appren_kelly_hired

Hopefully, that makes the reasoning a bit more clear. One of the
problems we want to solve is in the cases that a RSS feed can only
publish the playerUrl (for whatever reason). How do we efficiently
allow the feed to include all interesting meta data about the media
object (such as real height/width)? From the search perspective, we
want this information since we can't actually "touch" the media
object to determine it ourselves.

Solving this problem should also help actual alternative clients
using RSS.

David Hall
Yahoo! Search