Action-126: Proposal to materialize ldp:contains

Per the Jan 13 resolution [1], this action was to propose a syntax used to 
communicate a client's desire for a server to materialize ldp:contains in 
representations delivered to the client 
This email should satisfy that action.

Since the proposal solves a problem similar to what we have solved 
differently today for non-member properties, I included in this draft the 
mechanism by which it could cover non-member properties as well, since we 
tend to favor consistency.  If we go this route, we have the option of 
replacing all of the existing non-member properties interactions with this 
(which does, to me, seem like a net reduction in complexity for both 
client and server).  A pleasant side effect is that if we (or others) find 
new ways to torture graphs usefully in the future, this draft allows those 
itches to be scratched easily. 

Using the existing [2] HTTP Prefer header defined in [3], we register a 
new preference in the same basic manner that we define the Accept-Post 
header, following the preference registration procedure in [3] section 
5.1.  This amounts to (a) we fill out a short form and place it in our 
spec ... content below, and (b) we email IETF for a review.  People has 
asked about it's status: according to the author, it is queued behind 
httpbis (but otherwise approved) because of a normative dependency on a 
few ABNF productions; httpbis's status page indicates that all but p1/p2 
are approved/announcement pending, and p1/p2 are in IESG evaluation ("Last 
Call" was the term [3]'s author used).  Once bis is stamped with an RFC 
number, [3] should follow immediately with its own.

Careful readers will note that Prefer is a client hint (servers can ignore 
it, as is true of most/all existing HTTP headers).  In the draft below 
I've dealt with the WG's Must resolution at the LDP level as best I can, 
given that we cannot use the Expect header, see [4] final paragraph (short 
version: httpbis intentionally removed its extensibility because "no one" 
ever implemented it/correctly).  I was not aware of this on the last call, 
obviously.

In the LDP spec:
New, ala 5.9.1, but in LDPC-general: 
LDP servers Should respect all of a client's LDP-defined hints to 
influence the set of triples returned in representations of an LDPC, using 
the mechanism described in [link to registration], particularly for large 
LDPCs.  Note: The response might be [paged]; paged representations provide 
no guarantee that all triples of a given subset, for example containment 
triples, are grouped together on one or on a sequence of consecutive 
pages.

EMAIL NOTE:  Should rather than Must allows servers that somehow know they 
only host small LDPCs to just ignore Prefer and always return everything, 
which should reduce their implementation cost.  Our old "keep the simple 
case simple" thought.  If the WG prefers Must, I can live with that, 
however some would no doubt read that as a constraint that Prefer's 
definition prohibits.  I can live with "strongly Recommended" too.  If 
clients somehow knew they were dealing with those "sans prefer" servers, 
they could also ignore it, although the savings is negligible in all cases 
I can think of.

EMAIL NOTE:  The "named graph" part of Alexandre's resolution 2 (that he 
reminded Henry about this past week) should set the normative expectation 
that the contains triples are part of the state, and therefore retrieving 
a representation of that resource (in the absence of an omit "opt out" 
from the client) would normally return them.  LDP could try Must'ing that, 
at the risk of eliciting more comments along the lines of Mark Baker's 
(and perhaps Erik W, and IETF generally) that we're intruding on base 
specs by over-specifying how servers form representations most appropriate 
to the client according to WebArch.  I'm going to share this email with 
[3]'s author to get his take on any likely IETF reactions, based his 
experience with the review process for [3] (which from what I see in the 
list of drafts is >5 years long).

EMAIL NOTE:  The definition of Prefer is sufficient IMO to tell clients 
that even if they prefer-omit, they may still get back "extra" (from their 
app-specific point of view) triples.  The Should above, assuming it 
remains anything less than Must, is just another reinforcement of that.


Examples:
Prefer: omit; ldp-containment
Prefer: omit; ldp-containment; ldp-membership

The latter is equivalent to today's non-member-properties content.

The draft registration template content is:
   o  Preference: omit

   o  Value: None are defined.  Other specifications MAY add them, but not 
all LDP servers will understand them.

   o  Optional Parameters: 

Each of the following parameters is either present or absent, and takes no 
value. 

ldp-membership: the client's interest in membership information.
ldp-containment: the client's interest in containment information.

Other specifications MAY add new parameters, but not all LDP servers will 
understand them.

   o  Description: 

The omit preference is a hint from a client to help the server form a 
response, possibly a resource representation, that is most appropriate to 
the client.  It suggests the portion(s) of a resource's state that the 
client application is uninterested in, and if received is likely to be 
ignored.  LDP Containers with large numbers of associated documents and/or 
members will have large representations, and many client applications may 
be interested in processing only a subset of the LDPC's information, 
resulting in a potentially large savings in server, client, and network 
processing.

   o  Reference:  Linked Data Platform 1.0
   o  Notes: 

Server implementers are urged to consider the potential impacts on caching 
described at the end of [3] section 2.  If the server's responses *are* 
influenced by this preference, then a "Vary: Prefer" header is very likely 
required on responses.

Various syntaxes correspond to "no value is provided"; see [3] section 2 
ABNF productions 'preference', 'parameter', and the accompanying text.

This preference introduces no new security considerations.  Since it is 
used only to reduce the size of potential responses, it is *less* useful 
as a denial of service vector than the same request in the absence of the 
preference.

Clients using this preference will likely not benefit from being sent a 
Preference-Applied response header when only LDP-defined parameters are 
present.  For example, if the response includes at least one ldp:contains 
triple then a client can easily detect that 'omit; ldp-containment' was 
not honored.


EMAIL NOTE:  I looked at several syntactic alternatives within Prefer. 
There were others that to some degree I liked better at first, but I ran 
into potential issues like security/DOS aspects and a limit of one 
effective preference-token occurrence per request that I could avoid by 
reformulating to the syntax above, while still satisfying our current 
needs. I.e. I ended up KISSing it ;-)


[1] http://www.w3.org/2013/meeting/ldp/2014-01-13#resolution_3
[2] http://www.iana.org/assignments/message-headers/message-headers.xhtml
[3] tools.ietf.org/html/draft-snell-http-prefer-18
[4] 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-5.1.1

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario