Re: Lack of server controlled property in PUT?

On Fri, Oct 10, 2014 at 6:23 AM, John Arwe <johnarwe@us.ibm.com> wrote:

> > 1.  4.2.4.1 says: "LDP servers may ignore server-managed properties ...
> if
> > they are not under client control."
>
> > 2.  4.2.4.3 says: "If an otherwise valid HTTP PUT request is received
> that
> > attempts to change properties the server does not allow clients to
> modify,
> > LDP servers must fail the request by responding with a 4xx range status
> > code (typically 409 Conflict)."
>
> The confusion seems kinda obvious:
>
> - we use different words (server managed, under client control, allow
> clients to modify)
>
Ahh, we interpreted properties "not under client control" and properties
"the server does not allow clients to modify" as the same set.  And
therefore, "server-managed properties that are not under client control" as
a proper subset of "properties the server does not allow clients to modify".

Some questions on the use cases:

> As those in the WG will probably recall, there are (at least) the
> following classes of "server managed properties" ... and the classes can
> overlap
>
> 1: write-once (by client) ... e.g. dcterms:previousVersion
>
Doesn't this conflict with the note in .3 that says write-once properties
are *not* server-managed?

> 2: server supplies default:  clients can update (potentially only once),
> but server will compute a default value ... e.g. dcterms:created
>
The server providing a default value seems orthogonal to the client's
ability to modify?

> 3: server always computes a value ... e.g. dcterms:modified
>
4: read-only (by client) ... e.g. uuid, ldp:contains, membership triples in
> many implementations
>
I'm not sure of the difference between these two...  If it is read-only,
and the server doesn't provide a value, then it's the case where the server
does not allow a value to be set?

Or does .1 come from the difference between 3 and 4 -- some implementations
would ignore a change to dcterms:modified (always computes a value) so it
just gets overwritten, but reject a change to ldp:contains (read-only to
client)?

4a: server rejects requests to modify
>
4b: server silently ignores requests to modify (accepts the request, then
> immediately restores the previous value as if a subsequent request had done
> so)
>
These are interaction details, rather than use cases, I think.
Implementers MAY WISH TO [1] apply 4a or 4b in different situations
according to how they consider a particular property.

[1] http://tools.ietf.org/html/rfc6919#page-4


>  Further complicated by some people's interpretation that simply
> enclosing the value in a PUT request body constitutes "client intent to
> update", even if the value is identical to what's on the server, which
> others consider a perverse result - it means that a GET/PUT pair with no
> client-side modifications to the payload would fail if it contains
> server-managed properties, in the absence of .1
>
Count me in on the "that's perverse" side ... as *not* putting it in the
body would count as a request to delete for PUT. Otherwise how do you
delete a property?

Thus every PUT request MUST contain the server-managed properties to avoid
implying deletion, and thus under the definition where inclusion is
modification, every PUT would fail?


> .1 was an attempt to deal with the otherwise perverse result, by
> expliciting authorizing 4b's behavior.
>
.3 was (in part, at least) an attempt to deal with PUTs attempting to
> update membership or containership triples, ala 4a, without having to
> remember to update .3 every time we invent some new predicate.
>

Okay, some possible definitions from the use cases above

 * Server Managed:  The server has additional restrictions on the client's
ability to modify the property, and/or additional logic regarding the
existence and/or value(s) of the property
 * LDP Managed:  The additional restrictions or logic are due to following
the LDP specification.  (Thus all LDP managed properties are server managed
properties)

 * Default Supplied:  Until set, the server will provide a default value
for the property.  (Orthogonal to client's ability to modify)

 * Client Controlled: If there is a request from a client that attempts to
create, modify or delete an instance of the property for a resource, all
other things being equal, the server will process the request.
 * Write Once:  Once created by a client, the property may never be
modified or deleted.
 * Server Controlled:  The server will provide 0..n values for the property
that it may modify but clients cannot.


>  Strawman:
>
> - Define "LDP managed" properties as the set of properties constrained by
> LDP ... which might devolve to using the existing terms for membership
> triples and/or containership triples.
>
> - Define "server managed" properties as those that the server (1) computes
> or (2) treats as write once, but are not LDP-managed, whether or not they
> are ever updatable by clients.
>
I think defining server managed as not LDP managed is counter intuitive,
but for least change to the spec I see why you're doing it.  If server
managed is those properties that the server has some additional logic for,
then .1 is orthogonal to .3 which is about the read/write status of the
property.  If that fulfills the requirements then it's at least cleaner
than what we have now.


> - .1 is unchanged
>

A slight rewording of the middle section to unpack the definition might
help:

LDP servers MAY ignore properties that have server supplied values,
including their omission from the body of the request.

- .3 applies to containership triples, and possibly moves up to General
>

If it only applies to containment triples, isn't it already covered by
5.2.4.1 ... and wouldn't there be a conflict between 4.2.4.3's MUST and
5.2.4.1's SHOULD ?

And isn't there a conflict already?


> -- we know we have use cases to patch *membership* triples, still allowed
>
+1

> -- I can't think of a single case where a client is/should be allowed to
> update containership triples, regardless of the method used
>
+1

> - .3 add non-normative note that clients should expect the same behavior
> if they attempt to change the value of (sic - the GET/PUT case carefully
> handled) server-managed properties ... preserving the original intent of 4a
>
+1.  It's not a requirement, but the server MAY always choose to reject
changes for some reason.

> -- optional: move to general ... same arguments would apply to patch
>
+1.  The same rules should apply to any attempt to change things, not just
via PUT.


Thanks John!

(If there's incomprehensible nonsense in this mail, it's because I've
rewritten sections multiple times, starting right after the call)

Rob


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305