The reliance on Content-type

[Ernst Johannes]

I would like to throw in two more concerns, none of which are  
necessarily fatal but which bother me a bit:

1) The HTTP capabilities request can only be invoked by identity- 
aware software, NOT by the browser. In other words, the user has no  
mechanism of "trying it out" (like we sometimes dial fax numbers from  
our phones just to check that there's a fax on the other side if it  
doesn't go through). So debugging is not that simple ... nor  
understand what actually happens by examining a running system.

2) This proposal "abuses", to a certain extent, the intentions behind  
HTTP content negotiation, because we are NOT returning the same  
resource at the same URL, but something that's quite different. As  
far as I understand the philosophy behind it, HTTP content  
negotiation is supposed to be used in order to express, for example  
when requesting a document, "give me the HTML version of the  
document, if you don't have, give me plain text and Word as last  
resort" or stuff like that: they are all referring to the same  
document with (presumably) the same content. Per the current wiki, we  
are using the same URL to request entirely different content, such as  
the user's home page vs. a very technical capabilities document. The  
case that they have the same content is practically non-existent (at  
least on the first leg).

These two are larger concerns to me than the one Martin voices (but  
which I agree with), my argument being: if somebody can write a  
script to detect whether or not to return this or that content, based  
on HTTP content negotiation, they most likely know to specify the  
MIME type of what they have returned. (Martin's concern may only be  
about the second leg of the indirect case, where he's right)

(Note that these concerns where the very reason why originally had  
the meta=lid / meta=capabilities arguments -- this problem is far  
smaller when doing so.)

I don't want to shake hard-won consensus if I can avoid it, but I  
wanted to bring this up to see whether others share my concerns.


On Nov 10, 2005, at 0:15, Martin Atkins wrote:

>
> The current spec relies on the returned Content-type value to  
> determine
> what kind of document has been retrieved. This is how HTTP was  
> intended,
> but in the real world most website owners don't know how to or can't
> configure a specific content type for a resource on their site.
>
> In these cases, the XRID file will probably get served as either
> text/plain or text/xml. Per the current spec, that would cause the
> consumer to flag an error.
>
> I propose, for the sake of "Let's be realistic, here!", that we make a
> special allowance for this problem, but *only* in the HTML  
> indirection case.
>
> Per the current spec, the HTML indirection case involves a LINK  
> element
> like the following:
> <link rel="identity.capabilities"
>       type="application/xrid+xml"
>       href="http://myid.example.com/capabilities">
>
> The type is spelled out in the LINK element here. My proposal is  
> that in
> the case where the type given here is correct, consumers be instructed
> to disregard the type returned by the server and attempt XML  
> parsing. If
> the root element's namespace is wrong or the document is not well  
> formed
> at all failure will soon follow. Consumers should still pay  
> attention to
> other aspects of the response, including making sure that the status
> code is 200 OK. That way they can fail early if it's a 404 Not Found.
>
> The direct access case is assumed to be used only by people who "know
> what they're doing", so we can keep that case simple.
>
> This does make things a little more complicated, but I think it's
> important for early adoption.
>

Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051110/64ccd95d/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst