Re: Action-126: Proposal to materialize ldp:contains

Hi John,

On 01/18/2014 10:39 AM, John Arwe wrote:
> 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.

Thanks for this draft. In short: I really like the direction this is
taking. Please find my comments below.

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

I agree with the claim that the proposed mechanism is easily
extensible to other cases.

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

With your proposal, LDP will depend normatively on this, so we'll have
to hope that these dependencies will become stable soon enough for LDP
to go to REC.

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

I personally don't think that a MUST makes much sense here and that
SHOULD captures the fact that the server can always ignore the Prefer
header. I could also live with the other solutions but I don't think
this is really realistic.

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

The Named Graph resolution + [1] already clearly make the containment
triples part of the LDPC state. I don't think that we have to add a
MUST there but I wouldn't be against a remark making explicit that the
containment triples would be returned by default in a GET.

> that we're intruding on base
> specs by over-specifying how servers form representations most appropriate
> to the client according to WebArch.

Can you say why you think this is "over-specifying"?

>  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

Clear, precise. /me likes it!

>
> 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 ;-)

I guess we will discuss the content of this registration but a first
read looks ok to me.

I have two related questions with the proposal:

1. Does this replace 5.9.1 altogether? Do we still expose non-member
and non-containment resources?

2. The spec does not prevent inlining (nor encourage it) and it _can_
be useful for a hashless-ContainerResource to inline the containment
triples from the related containers. I would then expect those
"normally" inlined containment triples not to be returned if the
client prefers to omit them. If you agree, do you think we should have
a remark that mentions inlining in this proposal?

Alexandre.


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

Received on Saturday, 18 January 2014 21:09:09 UTC