Proposal: add Prefer: include

This is a separate proposal that builds off of Prefer: omit [1], based on 
offline feedback.  [1]'s content *is not affected* by this proposal. 

At least one offline critic felt that, while "omit" solves the problem 
it's supposed to, "opting out" is unnatural for some and perhaps less 
extensible over the long term, since clients with performance concerns 
might "continually" have to learn about new things to opt out of, rather 
than opting in to "only what they intend to process" at the moment.  I did 
look at a flavor of this while drafting [1], I simply decided then that 
since it was not strictly required and it Might be more controversial as a 
DOS vector I'd KISS [1].  Now that someone has asked, here is the delta 
that could be added on.

- you keep the same "LDP servers Should respect all of a client's 
LDP-defined hints " that [1] has.  this is just a new hint that falls into 
that "existing" (proposed) text.
- you register a second preference token (draft below - it's JUST 
s/omit/include/* and then tweaking the description) ... there is a new 
security consideration however, which is another thing that led me to back 
of from it/similar mechanisms when proposing [1]
- you re-use the same LDP-defined parameters from the omit preference
- you say something about how they interact if they are conflicting 
(potentially contentious - easy default is {since Prefer is already 
defined by [3] as a hint} the server behavior is simply 
undefined/implementation dependent ... this is no different than saying 
some/all of the hints were ignored, as [3] and [1] already allows).

Examples: 
Prefer: include; ldp-containment 
Prefer: include; ldp-containment; ldp-membership 
The latter is equivalent to today's non-member-properties content. 
The draft registration template content is: 
   o  Preference: include 

  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 include 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 interested in, and if received is likely to be 
processed.  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 has similar new security considerations to the 
'return=representation' preference [3].  Since it can be used increase the 
size of potential responses, it can be a denial of service attack vector. 

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 'include ; ldp-containment' 
was honored. 


[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0086.html
[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