Subject: Posted PaceEnclosuresAndPix

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 13:36:06 -0800

There are a couple of areas where we don't quite have feature parity 
with RSS2.0, this tries to address that: 
http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix  -Tim

---

From: Lance Lavandowska <[email-masked]>
Date: Wed, 5 Jan 2005 16:28:11 -0600

Actually, I recall this has been discussed previously (providing
Enclosure-like support) [1 for an example] which eventually pointed up
the PaceLinkRelated[2] which covered much of the same ground.  But
your proposal raises a few questions/comments on my part:

1) There has been some controversy as to the "arbitrary" restriction
of one enclosure per item in RSS.  Should we duplicate that
restriction?  If so, why?

2) Why not have an 'image' link in an entry?  I recall discussion of
using &lt;content src="..."%gt; or somesuch for graphics, but has a
Flikr-like usecase been discussed?  Using an 'image' link and regular
content seems appropriate.

3) On the 'size' attribute.  'size', 'length' and 'content-length'
have been proposed ('length' is in the PaceLinkRelated [2].  I prefer
(content-)length, as size appears ambiguous.

4) Perhaps we could add a 'dimension' attribute for images? kidding.

Lance

[1] http://www.imc.org/atom-syntax/mail-archive/msg03805.html
[2] http://www.intertwingly.net/wiki/pie/PaceLinkRelated

---

From: Graham <[email-masked]>
Date: Wed, 5 Jan 2005 22:26:28 +0000

> http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix  -Tim

I can understand the enclosures one, but has the image tag in RSS ever 
served a useful purpose? Without any standard size they're very hard to 
incorporate into most layouts. Every usage of them I've seen has always 
looked very awkward because of this. A reliable way to locate favicons 
would actually be useful.

(I'd like some explanation of why the two proposed elements are 
crowbarred into the link element, btw)

Graham

---

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 14:52:21 -0800

> of one enclosure per item in RSS.  Should we duplicate that

Based on the discussion at  
http://www.reallysimplesyndication.com/2004/12/21#a221 and  
http://www.reallysimplesyndication.com/comments? 
u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndication 
.com%2F2004%2F12%2F21%23a221 I'm inclined to agree, don't see much of a  
downside for Atom.

> content seems appropriate.

I'm adding these things because they're actually deployed and used.   
There are a lot of things we could we could ask "why not" about.

> (content-)length, as size appears ambiguous.

Oops, right.   -Tim

---

From: Antone Roundy <[email-masked]>
Date: Wed, 5 Jan 2005 15:46:35 -0700

If we're going to restrict how many enclosures and/or images an entry 
can have, we should build that kind of information into the @rel 
registry, and it might be good, if possible, to come up with some kind 
of policy or guideline for how to determine whether such a restriction 
will be applied to future @rel values.  Given (what I suspect would be) 
the difficulty of coming up with such a policy, I'd prefer not to have 
any such restrictions.  And if we do decide to have such restrictions 
for images and enclosures, then perhaps <link> isn't the right way to 
point to these resources.

BTW, is PaceLinkPurpose completely dead or is it still gasping for life 
while waiting for language to be written[1] that consensus can be built 
on?  If the dream is not dead, then I don't think <link> is the right 
place for images, and perhaps not for enclosures either, though I 
wouldn't argue strenuously against that.

Antone

[1] http://www.imc.org/atom-syntax/mail-archive/msg11631.html

---

From: Antone Roundy <[email-masked]>
Date: Wed, 5 Jan 2005 16:04:06 -0700

On Wednesday, January 5, 2005, at 03:26  PM, Graham wrote:
> served a useful purpose? Without any standard size they're very hard 
> to incorporate into most layouts. Every usage of them I've seen has 
> always looked very awkward because of this.

I've found it useful, and haven't thought it that difficult to deal 
with the odd sizes.  If you're using an HTML widget to do your layout 
(or converting to HTML and embedding in a web page), all you have to do 
is specify a width attribute in your img tag (and set the width the 
same for each image) and the image will get scaled, automatically 
maintaining the correct aspect ratio.  The heights won't all be the 
same, and if a particular souce image is smaller than the width you've 
chosen, you'll get some pixelation[1], but I've found the results to be 
entirely satisfactory in most cases.

[1] If the XML specifies the image width, or if you check the 
dimensions of the images, you can often leave smaller images at their 
original size rather than scaling them up, depending on your layout.  
If, for example, you're floating images to one side, it's much more 
important to scale down large images than to scale up small ones to get 
your layout to look decent.

So yes, to some of us at least, it is useful.

Antone

---

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 15:03:21 -0800

On Jan 5, 2005, at 2:26 PM, Graham wrote:

> always looked very awkward because of this. A reliable way to locate 
> favicons would actually be useful.

I think Graham's right.  In fact, I just looked around and I can't find 
any software that still actually uses them... unless someone shouts 
"keep it" I'm inclined to lose it. -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 15:25:58 -0800

On Jan 5, 2005, at 3:04 PM, Antone Roundy wrote:

>> I can understand the enclosures one, but has the image tag in RSS 
>> ever served a useful purpose? Without any standard size they're very 
>> hard to incorporate into most layouts. Every usage of them I've seen 
>> has always looked very awkward because of this.
>
> I've found it useful

Where?  I haven't been able to find anywhere that's actually using 
them.  Bloglines used to, but no longer. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 05 Jan 2005 15:54:39 -0800

> them.  Bloglines used to, but no longer. -Tim

Bloglines still uses it in some places:
http://bloglines.com/preview?siteid=2213

Hmm. I don't know of any GUI clients that show them (web stuff like 
Magpie and Amphetadesk can be made to do it), but what's a LiveJournal 
feed without a photo?

http://www.livejournal.com/~brad/data/rss
http://bloglines.com/preview?siteid=530866

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Wed, 5 Jan 2005 16:59:35 -0700

> them.  Bloglines used to, but no longer. -Tim
A quick look through my cache files turns it up in five feeds (though 
only for a channel image, not item images).  The feeds come from 
WashingtonPost.com, Slashdot, CNET News, Wired News, and yes, Ongoing.

A quick grep of the cache files from my Jawfish service (which converts 
RSS to JavaScript for display on sites that can't do it some other way) 
turns up 611 feeds containing an <image> element, all of which appear 
to use it only for channel images.

Okay, I guess it's been a while since I knew where to find a feed that 
used <image> in <item>s.

---

From: Ray Slakinski <[email-masked]>
Date: Wed, 5 Jan 2005 19:03:01 -0500

On 5-Jan-05, at 5:52 PM, Tim Bray wrote:

> u=reallySimpleSyndic&p=221&link=http%3A%2F%2Fwww.reallysimplesyndicatio 
> n.com%2F2004%2F12%2F21%23a221 I'm inclined to agree, don't see much of  
> a downside for Atom.

I would like to see Atom support multiple enclosures because I feel the  
1 enclosure per item/entry is quite limiting when sending out separate  
files of related information. I like to use the email analogy when  
talking about enclosures. In the current implementation of RSS, you  
would be restricted to only adding one attachment per email. But say  
you have 4 baby photos that were taken during his/her first birthday.  
Now I have to send out 4 emails to the same person, the first one with  
a description and a photo, and 3 other emails with each other photo. In  
addition to being cumbersome, there is no good way to show that the  
photos all go together. With multiple enclosures I can group all that  
related information together.

Dave does bring up some good points about duplicating a lot of extra  
information inside the enclosure tag, but I feel that most data can be  
either inherited from the encasing item tag or is encased in the file's  
own metadata. An ID tag per file is all that would be needed to keep  
the files separate and distinct.

Because they see value in several files per item, Yahoo is now trying  
to extend RSS to support multiple enclosures. Should we not solve this  
need prior to having to tack on extra layers later?

[-----]
Ray Slakinski
Fingerprint: C8AD 4847 2DA8 3469 079D  13F9 135D F0CF 1CFC FD03

Blog: http://ddll.sdf1.net

The verdict of a jury is the a priori opinion of that juror who smokes
  the worst cigars.
  		-- H. L. Mencken

---

From: Danny Ayers <[email-masked]>
Date: Thu, 6 Jan 2005 01:25:01 +0100

> http://www.intertwingly.net/wiki/pie/PaceEnclosuresAndPix  -Tim

I could live with this Pace, feature parity and ease of migration
being good justification for the approach. But  -

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?

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)

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

4. What do we call an inline (i.e. base64 encoded content) media
object - an attachment?

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Brent Simmons <[email-masked]>
Date: Wed, 5 Jan 2005 16:36:08 -0800

On Jan 5, 2005, at 3:54 PM, Robert Sayre wrote:

>>>> ever served a useful purpose? Without any standard size they're 
>>>> very hard to incorporate into most layouts. Every usage of them 
>>>> I've seen has always looked very awkward because of this.
>>>
>>>
>>> I've found it useful

Some GUI apps do display feed-level images. Here's a screenshot: 
http://ranchero.com/images/bradsLife.png

But, since they are of varying sizes, they tend to be tucked away in 
the UI rather than displayed prominently. Were there a standard size, 
then a GUI app could do something like how iTunes displays album cover 
art.

-Brent

---

From: Robert Sayre <[email-masked]>
Date: Wed, 05 Jan 2005 16:39:42 -0800

> 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>

> 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.

> 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

We call it the "content", which comes from the <content> element, whose 
  definition says it conveys the "content" :)

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 17:04:39 -0800

> be delivered using some form of the <content> element?

I used to think that, but we observe in the RSS2 world that there's a 
well-accepted use case for something that's specially designated for 
different handling.  Why fight it?

> be expressed using mime types? Example:

I'm pretty well convinced that multiples can't hurt.

> go in the <link> registry - separation of concerns and all that

That's because it's done as a delta to FieldingLinks, the new languages 
goes in a couple of places in that section so I just preserved it.

> 4. What do we call an inline (i.e. base64 encoded content) media

Nope, that's just <content>  -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 17:06:59 -0800

> then a GUI app could do something like how iTunes displays album cover 

Hmm... sounds like it does no harm.  Think we could get away something 
like "The aspect ratio of the image SHOULD be 3:2 and software MAY 
resize it as desired."? -Tim

---

From: Brent Simmons <[email-masked]>
Date: Wed, 5 Jan 2005 17:22:27 -0800

On Jan 5, 2005, at 5:06 PM, Tim Bray wrote:

>> then a GUI app could do something like how iTunes displays album 
>> cover art.
>

For me that would work quite well.

I'd like very much to make feed images more prominent, for UI reasons 
-- some of the graphics I've seen are interesting, and, more 
importantly, they provide a visual clue to the source of what you're 
reading.

-Brent

---

From: Ray Slakinski <[email-masked]>
Date: Wed, 5 Jan 2005 21:16:13 -0500

> I'm pretty well convinced that multiples can't hurt.

Sorry I was confused by your first post then.  I'm very pleased that 
its more than a remote possibility to have this in Atom.

I was wondering though about being able to identify one attachment from 
another.  I suggested an ID before, and I think the ID could work well 
to solve some of the logistical issues with multiple enclosures.

For Example:

<link rel="enclosure" href="http://mysite.com/mysong.mp3" 
content-size=102040 id=1>
<link rel="enclosure" href="http://mysite.com/mysong.mp3.torrent" 
content-size=1245 id=1>
<link rel="enclosure" href="http://mysite.com/mysong2.mp3" 
content-size=50232 id=2>
<link rel="enclosure" href="http://mysite.com/linernotes.txt" 
content-size=10 id=3>

The ID element would be an optional just like content-size would be.

[-----]
Ray Slakinski

A person is just about as big as the things that make them angry.

---

From: Danny Ayers <[email-masked]>
Date: Thu, 6 Jan 2005 14:04:04 +0100

+1 it is then.

(with multiples, and including the aspect ratio/resize hint - that
seems good pragmatism)

-- 

http://dannyayers.com

---

From: James Snell <[email-masked]>
Date: Thu, 6 Jan 2005 09:37:29 -0800

Pardon me for stepping in on this conversation in the middle, but it
has brought to mind a question about whether or not Atom should
support the ability to specify a hash value for resources linked to
using the link mechanism.  The link can be used, for instance, to
verify whether or not the resource being linked to has been modified
since the link was created.  This is particularly relevant to
enclosures which may be of arbitrary content type and involve the user
downloading bytes to their computers.  Perhaps we should add two new
attributes to the link element?

 <link rel="enclosure" href="http://example.com/somefile.mp3"
         hash="{generated_hash_value}" 
         hashalg="{uri_identifying_the_hash_algorithm_used" />

The hash and hashalg attributes would be optional but MUST appear together.

Thoughts? (If we have more than two people respond favorably to this,
I'll write up a Pace for it)

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]

---

From: "Roger B." <[email-masked]>
Date: Fri, 7 Jan 2005 13:48:34 -0600

> In
> photos all go together.

Ray: There are several, IMO.

(1) Put them all in the same rss:category.

(2) Use ENT and assign them all at least one common topic.

(3) Put them in a distict feed.

At least one of those is fairly trivial for just about every app out
there, and all of them are better than treating a single item as a
content dump, IMO.

 --
Roger Benningfield
blog: http://admin.support.journurl.com/

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 08 Jan 2005 17:33:07 +0000

> I'll write up a Pace for it)

Seems like a good idea - would it be possible to move them into elements?

   <link rel="enclosure" href="http://example.com/somefile.mp3" >
     <hash hashalg=""/>
   </link>

How does that tee up for signing the markup, or just the hash+alg pair?

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sat, 08 Jan 2005 15:02:27 -0500

> Seems like a good idea - would it be possible to move them into elements?

Well, Content-Length lives in the attributes as "length", but I don't 
think we need to make a home for every HTTP header. Content-MD5 will 
work just fine; it would probably be wise to send a HEAD request before 
automatically downloading a giant mp3. Furthermore, you'll get a good 
enough identifier by concatenating the URI and the length. Something 
more accurate will require a HEAD request. Thirdly, there's absolutely 
no reason to have this in core.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sat, 8 Jan 2005 20:28:02 +0000

I require this functionality in <content src="">. There is aboslutely 
no way I'm initiating 20 HTTP requests (even HEADs) each time the feed 
is reloaded.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 08 Jan 2005 15:44:58 -0500

> no way I'm initiating 20 HTTP requests (even HEADs) each time the feed 

Can you explain why you would need to initiate HTTP requests for 
<content src="">? I don't understand.

<feed ...>
...
<entry>
...
<content src="some.jpg" type="image/jpeg" />
</entry>
<entry>
...
<content type="HTML">&lt;img src="some.jpg"></content>
</entry>
</feed>

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sat, 8 Jan 2005 20:49:55 +0000

Well, for that example, it's not so necessary. But I've heard of one 
suggested usage being:

<content src="body.html" type="text/html" />

Which would require reloading to maintain feature parity with 
non-external content.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 08 Jan 2005 15:59:20 -0500

> Which would require reloading to maintain feature parity with 

http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2

"If the value of type begins with "text/" or ends  with "+xml", the 
content SHOULD be local; that is to say, no "src" attribute should be 
provided."

If you want to suggest language that describes the bad things that could 
happen when people ignore that recommendation, I would be happy to 
include it.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 09 Jan 2005 00:27:57 +0000

> no reason to have this in core.

I'm fine with all that - a good rationale. But no-one's asking to make a 
home for every HTTP header here.

cheers
Bill

---

From: Janne Jalkanen <[email-masked]>
Date: Sun, 9 Jan 2005 02:31:31 +0200

> Which would require reloading to maintain feature parity with

How about putting HTTP etags directly in the feed?

<content src="body.html" type="text/html"
etag="whatever:weird:system:you:have" />

Might work for enclosures as well...

/Janne

---

From: Eric Scheid <[email-masked]>
Date: Sun, 09 Jan 2005 12:20:31 +1100

> no way I'm initiating 20 HTTP requests (even HEADs) each time the feed

that's what the /feed/entry/modified date is for.

e.

---

From: James Snell <[email-masked]>
Date: Sat, 8 Jan 2005 18:14:50 -0800

I really don't want to be going down the road of requiring HTTP header
equivalents in the Atom feed, etc.  All I want is the ability to
specify a hash of whatever it is that is being linked to.  It could
work in both link and content elements and one could easily use the
Content-MD5 header to verify whether or not the resource referenced
has been modified since the time it was included in the Entry.

The URI and the length of the file do not guarantee that the content
has not changed and yes, I had considered this as a possible non-core
extension but wanted to float it as a core item first.

---

From: Robert Sayre <[email-masked]>
Date: Sun, 09 Jan 2005 17:07:37 -0500

>extension but wanted to float it as a core item first.

The level of accuracy you're looking for can't be achieved without 
specifying which HTTP request headers can influence the content returned 
(e.g. "Accept"), and what their values must be in order to receive the 
content with the hash given. For example, content negotiation could be 
really handy for podcasts (mp3, aac, ogg, wma).

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Mon, 10 Jan 2005 09:33:09 -0800

This is really cache management. Use e-tags, from the HTTP 1.1 spec.
Or use an HTTP cache, which would require no changes to Atom.

Going thorugh a client-side HTTP 1.1 cache would automatically take
advantage of the e-tags and other caching information in HTTP.

wunder

--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Martin Duerst <[email-masked]>
Date: Tue, 11 Jan 2005 16:46:35 +0900

>"If the value of type begins with "text/" or ends  with "+xml", the 
content SHOULD be local; that is to say, no "src" attribute should be provided."
 >If you want to suggest language that describes the bad things that could 
happen when people ignore that recommendation, I would be happy to include it.

When I read this, I was somewhat surprised to find a SHOULD.
A should, in IETF terms, is really quite strong. I'd prefer
a wording such as:

"In general, content with value of type beginning with "text/" or
ending with "+xml" will be inline; that is to say, no "src" attribute
is provided."

(and I think inline is the better term; local implies on the user's
machine rather than inside the document)

In both cases, adding something like "Such content is usually
short, and in that case, carrying it inline is more efficient."
covers the rationale I know about. There may be other rationales.

Regards,     Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 26 Jan 2005 06:11:28 +0100

> covers the rationale I know about. There may be other rationales.

- I think the word 'inline' is much better than 'local'. So no matter  
which wording is used in the specification, the content should be  
'inline', not 'local'.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»