Danny Ayers wrote:
1. If the media object is the primary content of the entry (which seems to be the main use case for RSS 2.0's <enclosure>), shouldn't it be delivered using some form of the <content> element?
Stick it in the content pane, don't bother preloading it. If you want the equivalent of RSS2, you can still do that with <summary> and <link>
2. Without multiple rel="enclosure", how does support and differentiate between media objects that are essentially the same resource but different formats, where the difference may not (easily) be expressed using mime types? Example:
"Tim's award acceptance speech" (pretty good quality: mp3, 16bit, stereo, 44.1kHz 128Kbit compression)
"Tim's award acceptance speech" (for saddos like danny with dialups: mp3, 12bit, mono, 11.025kHz 56Kbit compression)
The mime type should have parameters for that stuff, shouldn't it? Doesn't seem like our problem.
3. I don't think this Pace is the right place for listing what should go in the <link> registry - separation of concerns and all that
Doesn't matter.
4. What do we call an inline (i.e. base64 encoded content) media object - an attachment?
We call it the "content", which comes from the <content> element, whose definition says it conveys the "content" :)
Robert Sayre
