Re: Content type for /site-meta (or HTTP header fragment format)

On 29/11/2008, at 9:31 AM, Eran Hammer-Lahav wrote:
>
> I would like /site-meta to list a single text-based format with a  
> clear
> Content-type associated with it.

+1; there seem to be enough people supporting this approach to make it  
more likely to succeed.

> I also want the spec to explicitly allow
> user-agents to request other representations of the /site-meta  
> resource with
> the default being the super-simple-text-based version. One such
> representation (I expect to be widely supported) will be
> application/xrd+xml.

Agreed, but I don't think much needs to be said about this; something  
to the effect that the textual format is required (if the resource is  
present at all), but that other formats can be negotiated for.

> - Should the /site-meta text format be restricted to a set of links or
> provide an easy path for extensions of some other kinds of records?

This is a tricky question; if it's too open, people can throw whatever  
they like in, which may diminish the value of it over time. My  
inclination is to only allow links, but to allow extension metadata on  
the links.

> - Should /site-meta define its own content type, use an existing  
> content
> type, or define a new generic content type?
>
> If we take the route of using an HTTP-header-like format for /site- 
> meta, is
> there value in making this format generally available for other  
> resources.
> RFC 2616 offers a similar construct in the form of message/http. It  
> seems
> that as long as the document can be considered a valid HTTP request or
> response, we can use this content type.
>
> So /site-meta can be considered a body-less HTTP response with Link  
> headers.
> The question is, is such a header-fragment allowed in a message/http
> document? It is not clear if in this use-case, the Date header may be
> omitted, which is otherwise required for a valid response header.  
> The Date
> header makes little sense in this context and should be omitted.  
> Note that
> the HTTP header for GET /site-meta must still include Date.

Syntactically that could be true, but it's a stretch to say it's a  
message/http semantically, in particular because the links are defined  
as applying to the whole site, not just one message (as they are in  
the link header). I'd prefer to see a new media type that's less  
ambiguous.

Putting this together, that means that the site-meta format would be a  
line-separated list of link-values (i.e., the header syntax without  
the "Link:" part), and have a specific media type (e.g., text/site- 
meta).



--
Mark Nottingham     http://www.mnot.net/

Received on Saturday, 29 November 2008 00:29:46 UTC