Re: Lack of server controlled property in PUT?

> 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".

Good to get part of the difference/confusion diagnosed.

I'll just note here: if you believe in CRUD, and if you believe U=update = 
modify, then they would not be the *same* set, and the "proper subset" 
relation would be reversed vs your quoted statement. 
Some people do believe those conditions, and the resulting implication.

Also note that HTTP PUT can function semantically as either create or 
update, depending upon the prior existence of the resource identified by 
the request URI.
My reading of 4.2.4.1 is that "replace" covers both cases, and 4.2.4.3 
covers modify (hence the change/modify words) but not create; although in 
practice since it is true as you note that servers can reject requests for 
all sorts of reasons, my "but not create" might make no practical 
difference.

> Some questions on the use cases: ...
> These are interaction details, rather than use cases, I think.  

I called them "classes" intentionally.  So we agree they're not use cases.

> 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?

Sigh, more sub-cases.
Nice to have a fresh reader who still sees the words as written instead of 
the cached copy in my wetware.
My best (albeit weaselly and weak) backward-looking defence is to point 
out that the note is non-normative.
More germanely though, "write-once" != "write on create only"; "write on 
create only" and "write once after create" are arguably distinct sub-cases 
if we continue to rely on the CrUd distinctions, which I think will help 
readers more than it will harm them.

> 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?

I did say that the classes could overlap.
3 is distinct from 4 if the property is optional, to cite one obvious 
case.
It's likely true that in a rigorous partitioning those concerns are 
orthogonal, but I haven't spend huge tracts of time thinking it through.

> Implementers MAY WISH TO [1] apply 4a or 4b in different situations 
> according to how they consider a particular property.

We appear to have consensus on this.
(And let anyone with a lesser-degree belt in RFC-foo be April-fooled into 
thinking 6919 supersedes 2119, look at its publication date and status - 
Google isn't the only org that does April Fool's jokes.)

> 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?

Assuming you support PUT, yes.  Hence the perverse result to be avoided. 
Implementations from the Submission timeframe tended to use Patch 
semantics instead of Put for updates, so it was not obvious to all at 
first.

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

I don't see a definition for "server supplied", so I cannot comment on the 
utility of this change.

> - .3 applies to containership triples, and possibly moves up to General
> ...
> And isn't there a conflict already?

I don't think there's a conflict in today's text.

5.2.4.1 Should Nots the PUT-modification of containment triples.  Thus a 
server might (although LDP discourages this) allow such modifications.
4.2.4.3 says *If* the only thing wrong with a Put request is that it 
attempts to modify something that the server prohibits a client from 
modifying, *then* ...

If the server implementation prohibits put-modification of containment 
triples, then
- 5.2.4.1 says it Should respond with 409
- 4.2.4.3 Musts failing the request (entirely compatible with 5.2.4.1), 
suggests 409 (ditto), and Shoulds a response body (net add to 5.2.4.1)

If the server implementation *permits* put-modification of containment 
triples, then
- 5.2.4.1 does not apply (its antecedent If condition fails to fire)
- 4.2.4.3 does not apply (its antecedent If condition fails to fire - 
precisely because of the implementation choice permitted though 
discouraged by 5.2.4.1)
- all other things being equal, the request succeeds, even if various WG 
members are holding their noses

> 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 ?

I think you're correct on the first implication (and it's not the desired 
result), but not the second (same argument as for existing text, above).

Maybe it simplifies out to .3 is also unchanged.  Once we define 
"x-managed" more obviously (for possibly >1 value of x), we should be able 
to collapse the now-differing terms.
Looking back on things, I see that the "server" in "server-managed" is 
particularly problematic ... we no doubt really mean "LDP-server-managed", 
but therein lies the hairbreadth difference that sets apart Heaven and 
Earth.  I wonder out loud if we change (really: add) the definition+name 
of "server-managed" to be "LDP-server-managed", to be as constrained by 
the LDP spec, and then note (perhaps alongside, or with link to, 4.2.1.6) 
the existence of additional constraints (not LDP imposed) that the server 
might have for rejecting any request), is this neatly wrapped up?

The thinking being that 
- calling them "LDP-server-managed" [wham] baby seals readers each time it 
comes up
- using that term consistently in place of today's varying language [wham] 
shaves off another set of unintended readings
- explicitly mentioning the (now distinct rather than overlapping) issue 
of other non-LDP constraints causing requests to be rejected [wham] 
untangles it from the LDP requirements


Best Regards, John

Voice US 845-435-9470  BluePages
z/VM OpenStack Enablement and zKVM