Subject: atom:content's src and server-driven content negotiation

From: Andreas Sewe <[email-masked]>
Date: Wed, 18 Jan 2006 13:05:24 +0100

I don't want to start yet another discussion about violating SHOULD 
level requirements but I can't think of any better way to handle the 
following situation (but hopefully you can :-):

Suppose the host www.example.com uses HTTP/1.1's server-driven content 
negotiation for its resource /img which has both image/png and 
image/svg+xml representations. Furthermore these representations can be 
accessed explicitly as /img.png and /img.svg, respectively.

Now a straight-forward way to compose an entry describing /img would be 
as follows:

<entry>
   <title>Some Example Image</title>
   <summary>A short summary of the example image</summary>
   <link rel="alternate" type="image/png"
         href="http://www.example.com/img.png" />
   <link rel="alternate" type="image/svg+xml"
         href="http://www.example.com/img.svg" />
   <content src="http://www.example.com/img" />
   <!-- author, id, updated -->
</entry>

Note, however, that a type attribute on the content element cannot be 
used since /img is a negotiated resource -- this violates the SHOULD in 
4.1.3.2.: 'If the "src" attribute is present, the "type" attribute 
SHOULD be provided [...].'

Of course one can compose an entry without a content element, simply 
listing /img among the alternate versions, but at least to me this 
feels, in the above scenario, wrong (although I cannot really put my 
finger on it):

<entry>
   <title>Some Example Image</title>
   <summary>A short summary of the example image</summary>
   <link rel="alternate"
         href="http://www.example.com/img" />
   <link rel="alternate" type="image/png"
         href="http://www.example.com/img.png" />
   <link rel="alternate" type="image/svg+xml"
         href="http://www.example.com/img.svg" />
   <!-- author, id, updated -->
</entry>

So do you have any suggestions how to best deal with a scenario like 
this? Which of the above entries is preferable?

Regards,

Andreas Sewe

---

From: John Panzer <[email-masked]>
Date: Wed, 18 Jan 2006 22:59:22 -0800

Andreas Sewe wrote:

> image/svg+xml representations. Furthermore these representations can 
> be accessed explicitly as /img.png and /img.svg, respectively.
>
> Now a straight-forward way to compose an entry describing /img would 
> be as follows:
>
> <entry>
> used since /img is a negotiated resource -- this violates the SHOULD 
> in 4.1.3.2.: 'If the "src" attribute is present, the "type" attribute 
I think this is a good example of why this is a SHOULD and not a MUST.  
(If Atom allowed an HTTP 1.1 media-range here instead of a MIME 
media-type you'd be set with "image/*" but it doesn't.)  In any case the 
spec explicitly tells implementors to pay attention to the server:

>If the "src" attribute is present, the "type" attribute SHOULD be
>   provided and MUST be a MIME media type [MIMEREG], rather than "text",
>   "html", or "xhtml".  The value is advisory; that is to say, when the
>   corresponding URI (mapped from an IRI, if necessary) is dereferenced,
>   if the server providing that content also provides a media type, the
>   server-provided media type is authoritative.
>
>  
>
So implementors who follow HTTP 1.1 content negotiation should be fine, 
those who don't will get whatever your default type is.  Or should.

-- 
John Panzer
Sr Technical Manager, AOL
http://journals.aol.com/panzerjohn/abstractioneer

---

From: Graham Parks <[email-masked]>
Date: Thu, 19 Jan 2006 11:17:38 +0000

On 18 Jan 2006, at 12:05 pm, Andreas Sewe wrote:

> Note, however, that a type attribute on the content element cannot  
> be used since /img is a negotiated resource -- this violates the  
> SHOULD in 4.1.3.2.: 'If the "src" attribute is present, the "type"  
> attribute SHOULD be provided [...].'

Note the next sentence:

"The value is advisory"

So it doesn't have to exactly describe the resource at the other end  
of the URL. The point is to give the consuming application a useful  
hint as to what kind of data is there.

> Which of the above entries is preferable?

The correct thing to do is to pick the one provided by default by the  
server when no content negotiation occurs. eg:

  <content type="image/png" href="http://www.example.com/img" />

Graham

---

From: David Powell <[email-masked]>
Date: Thu, 19 Jan 2006 11:53:00 +0000

>   <content type="image/png" href="http://www.example.com/img" />

Possibly, but that solution isn't perfect. There is a tradeoff between
supplying an inaccurate type, and supplying no type at all. This TAG
finding [1] discusses the issue quite thoroughly.

[1] http://www.w3.org/2001/tag/doc/mime-respect-20040225

The risk in providing an inaccurate mime-type in the content or link
elements, is that a user-agent such as a mobile device, might not
attempt to fetch the content at all if they don't support the advisory
MIME type, even though if they had requested the type, and conneg had
taken place, they could have been served a different type that they
could have handled.

-- 
Dave

---

From: Graham Parks <[email-masked]>
Date: Thu, 19 Jan 2006 12:19:36 +0000

> taken place, they could have been served a different type that they

If you read the W3C finding carefully, it doesn't actually cover this  
exact problem. It comes close in scenario 2 in section 2, section 4.1  
and section 5, but doesn't quite get there - all only cover when the  
advisory type is wrong outright, rather than misleading because of  
conneg.

The recommendation at the end of section 4.1 seems appropriate  
though. If the advisory type attribute is incompatible, the client  
should query the resource to double check, or at least offer the user  
the option of double checking and/or loading the resource anyway.

Graham

---

From: Andreas Sewe <[email-masked]>
Date: Fri, 20 Jan 2006 11:12:57 +0100

Graham Parks wrote:
> David Powell wrote: 

Thanks for the pointer. Very useful.

> The recommendation at the end of section 4.1 seems appropriate  though. 
> If the advisory type attribute is incompatible, the client  should query 
> the resource to double check, or at least offer the user  the option of 
> double checking and/or loading the resource anyway.

Yes, this suggests that labeling the negotiated resource with one 
specific media type *may* work, as long as the server falls back onto it 
as a default (as opposed to sending a "300 Multiple Choices" response):

<content type="image/png" src="http://www.example.com/img" />

But since my application currently does respond with "300 Multiple 
Choices", I guess that I am stuck with violating the SHOULD and using 
the following:

Or is there any better way to handle this, given that 300 responses are 
used?

At any rate, thank you all for your replies.

Regards,

Andreas Sewe