Re: Fw: [oslc-core] Proposal to remove Link header option from Resource Preview spec

[John Arwe <johnarwe@us.ibm.com>]

>     On responses to HTTP GET requests,
Providers MAY include a Link header
>     [RFC5988] for resources that support preview where

I would tweak first line to: On
responses to HTTP requests targeting existing resources, such as GET, Providers
MAY include a Link header
... GET is not so special; just common.
 It's the "existing" part that's important here (b/c of
the context URI value)

>     Providers MAY return a Link header
in responses to newly-created resources

"...responses to ... resources..."
is an odd read.  Perhaps: "successful responses to creation requests"

>     Link: <http://example.com/bugs/478?compact>; rel="http://open-
> services.net/ns/oslc#Compact",
>           <http://www.w3.org/ns/ldp#Resource>; rel="type"

I don't see the context URI being set to /478, so here it's /bugs.

> > Obligatory note from 5988 on that: when the context URI != the recipient has
> > to trust the server to make assertions about the context URI; thisis usually
> > true for us, but if POST (Create) to rtc9-foo.tivlab.ibm.com created a
> > resource on rtc-master.ibm.com, it's less obvious.  I'd just point to 5988
> > and minimize any restatement.
>
> Sorry, I'm not clear on this...
>
> Couldn't any ambiguity be cleared up by using an anchor on the Link header?

The point is not the ambiguity; [cue: obscure Monty Python reference] that's in a box by the door.
See http://tools.ietf.org/html/rfc5988#section-7 paragraph 2 final sentence.
See http://tools.ietf.org/html/rfc5988#section-5.2 paragraph 3.

In the example I cited, it comes down to (remembering that in this context the 201 response is saying roughly the following):
    POST /bugs HTTP/1.1
   HOST: rtc9-foo.tivlab.ibm.com
...
    HTTP/1.1 201 Created
   Location: http://rtc-master.ibm.com/bugs/478
   Link: <http://example-previews.com/bugs/478?compact>; rel="http://open-services.net/ns/oslc#Compact"; anchor="http://rtc-master.ibm.com/bugs/478",
         <http://www.w3.org/ns/ldp#Resource>; rel="type"

Why should any client trust rtc9-foo.tivlab.ibm.com (the server processing the request) to make assertions about rtc-master.ibm.com ?  This is what you get when you make the context URI something other than the default.  HTTP gives you no reason to trust server A to make assertions about server B (or, in general, for Resource A to make assertions about Resource B); you have to resort to something outside HTTP in order to trust (and therefore to use) the assertions.

So the net of the original comment was to elbow readers gently in the ribs by citing 5988 in the case where context URI != effective request URI, so readers coding clients can decide if they trust their servers (really: the effective request URI's resource) in that case.

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead