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/
