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/
