[Commentor] LC-2812 Mark Baker (archived comment) [Working Group decision] Thank you for your feedback Mark. While we didn't go as far as rewriting section 4 entirely, we've modified it to ensure that the specification doesn't seem to be redefining HTTP which was never the intent. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#conformance clarifies the overall relationship between LDP and HTTP; 4.6.1 was removed entirely as a result. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#base-specs and http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient were added to clarify consequences of base specs and how LDP clients differ from HTTP clients. 4.11 (at risk) was removed entirely. [Commentor reply] yes [Comment] 
Hi. I raised this issue before, but it was never resolved to my satisfaction, so I'm raising it again now at LC. Sec 4.6.1 says "LDPR servers must remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI must result in a 404 (Not found) or 410 ". This is bad because it redefines HTTP DELETE, which already has a well defined meaning in RFC 2616. The definition in 4.6.1 is more specific than the one in 2616, and it's why you need the LDP-specific Link response header which basically tells the client that the 200 response doesn't mean what it says in RFC 2616, but instead what it says in LDP 1.0. The correct way to do this is to simply reuse the definition in 2616 so that the client knows nothing about the state of server after a DELETE has completed. I'm not familiar with the use case that requires those post conditions on DELETE, but from experience I can't imagine why a client would need to depend on this specific behaviour. Let me be clear though, my concern is *only* with the interface between client and server, not with server behaviour. If you want to define that LDP servers have to behave in a certain way, go nuts. But as soon as that information leaks into the interface, you've crossed a line, leaking implementation details so that the client is coupled not to the interface, but the implementation. The same problem with DELETE exists elsewhere in section 4 too, including with PUT, though the definition seems close enough to 2616 that I'm not sure why it's being redefined. So in addition to those concerns about section 4, I'm also concerned with the requirements on client implementations and don't understand why they're necessary. Some seem purely superfluous, such as 4.3.5, as it's part and parcel of the RDF model that resources can have multiple types (not to mention the open world assumption). The same goes for 4.3.6. 4.5.2 falls under this category too because that behaviour is just one possible path through HTTP's conflict detection mechanism. 4.5.3 and 4.5.4 seem more like BCPs that anything needing to be conformance criteria. 4.5.5 just seems like a badly phrased constraint on server implementation that has nothing to do with a client. 4.11.3.3 says that a client shouldn't invoke GET, really? Are you concerned about DoS issues like the W3C's DTD problem? http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ There's no reason to make this a criterion of correct client behaviour AFAICT 4.11.3.4 also seems like it's part and parcel with the RDF model In short, I think section 4 needs to be completely rewritten so that it; - contains no client conformance criteria - contains no interface conformance criteria In addition, the mandatory Link header should be removed so that clients won't be tempted to treat server behaviour implementation conformance criteria as interface conformance criteria; all LDP servers would be indistinguishable from Web servers. Thanks.