- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Sun, 21 Oct 2012 21:53:17 +0200
- To: Mark Baker <distobj@acm.org>
- Cc: David Wood <david@3roundstones.com>, "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
Hi Mark, > Nothing else can be promised by servers or expected by clients, > at least without defining HTTP extensions. Why not? Any server is allowed to promise something more. If the client understands this promise, it can make use of the consequences. If it doesn’t, then it just uses HTTP (and that will work if there’s no contradiction). > As I mentioned before, servers are free to > *do* more, as that's an implementation consideration that HTTP doesn't > generally concern itself with. True, and the LDP spec defines a class of such servers. > But clients cannot *expect* more, > because expectation is defined by the contract alone. They can expect more if they agree this contract is the LDP spec, which is what an BPR client and BPR server will do. I’ve tried to summarize the possible options in a yes/no diagram: Currently, can BPR clients talk to BPR servers? Yes. Can generic HTTP clients talk to BPR servers? Yes. Can other RFC2616-compliant intermediaries talk to BPR servers? Yes. Can BPR clients talk to generic RFC2616 servers? No. Should they? No. If a client is designed for BPR servers, it can only be expected to work with BPR servers. Unless it's also a generic HTTP client. But then, it will apply the regular HTTP rules for non-BPR resources (otherwise, it’s not a generic HTTP client). Best, Ruben
Received on Sunday, 21 October 2012 19:53:51 UTC