Edit comment LC-2812 for Linked Data Platform (LDP) Working Group

Quick access to

Previous: LC-2833 Next: LC-2837

Comment LC-2812
Commenter: Mark Baker <distobj@acm.org>

Resolution status:


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

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. says that a client shouldn't invoke GET, really? Are you
concerned about DoS issues like the W3C's DTD problem?
There's no reason to make this a criterion of correct client behaviour
AFAICT 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.

(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: 2812.html,v 1.1 2017/08/11 06:47:13 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org