Comments on LDP spec (http://www.w3.org/TR/2014/WD-ldp-20140311/)

This seems like a good specification, and I don't see any major problems
with our implementing it, assuming some of my assumptions are correct (see
below).

I do have a few comments and questions:

4.2.1.4  Since an LDPR can be an LDP-NR, and the header must be included
responses to HTTP requests for all LDPRs, the following statement seems
incorrect:
"The presence of this header asserts that the server complies with the LDP
specification's constraints on HTTP interactions with LDPRs, that is it
asserts that the resource has Etags, has an RDF representation, and so on,
which is not true of all Web resources served as RDF media types. "

4.2.1.6  An example would be  useful here...

4.2.4.3 Server-managed properties are non-modifiable, and these can be
ignored, so this seems to contradict 4.2.4.1.  Perhaps this needs to be
qualified to exclude ignored server-managed properties.

4.2.4.4 Does the PUT succeed in performing an update in this case? Should
all requests with 4xx responses be assumed as having failed? Seems that it
would be more consistent if info was returned using describedBy link header
as mentioned previously for constraint violations.

4.2.6 HTTP HEAD
According to HTTP 1.1, "The HEAD method is identical to GET except that the
server MUST NOT return a message-body in the response." There is no mention
of OPTIONS, so why is OPTIONS mentioned in the context of HEAD? Also, why
not explictly say that HEAD MUST include the same headers as GET, so
clients can safely assume that.
These comments also apply to 5.2.6 HTTP HEAD.

4.3.1.3 I don't understand this statement.  "... MAY have an rdf:type of
only one of ldp:RDFSource ..." . Seems there is something wrong with this
sentence.

4.3.1.14 This seems like a good statement to make, and it should not be at
risk.

4.3.2.1 Shouldn't this say something like "... MUST provide a text/turtle
representation of the requested LDP-RS, unless otherwise specified via the
Accept Header"?

5.2.3.2 It appears that there is no requirement that ldp:contains be
included in responses to GET requests, which is good, since in our case
that would result in doubling the size of the container resource, and
doesn't provide any useful information to clients.

5.2.8 HTTP OPTIONS
There is an indication of additional HTTP OPTIONS requirements for LDPC,
but none seem to be described.

5.2.8.1 This doesn't seem to have anything to do with HTTP OPTIONS. Why is
it a subsection under HTTP OPTIONS?

7.2 Prefer header and return=representation
I assume that the default representation could omit the containment
triples, unless they are explicitly requested using Prefer header. That
would avoid having to double the size of LDPC representations for legacy
clients.
There is a statement below example 11 that seems to say this: "A server
that honors this hint would return (at least) the following response, and
perhaps only this (it might well omit containment triples if they are not
specifically requested)".

==================================
IBM Cloud & Smarter Infrastructure
Jazz for Service Management
joeross@us.ibm.com