Re: review of ldp-paging - sort criteria threadlet

> > 5. location and binding of sort criteria triples
> > Frankly, I'd really like to see the bit about clients sending this 
link 
> > header to be in this spec today.   I would be like a prefer header, 
> 
> Actually making it into a Prefer header parameter, rather than being
> "like" one, might be a starting point.  Return=representation 
> already carries conneg warnings in the RFC, so at least we'd make 
> things no worse by doing this.  Optimistically, the general Prefer-
> red ways of handling conneg "issues" may solve everything for us 
already. 

> Yeah, I guess Link is understood to be a Response Header, not a 
> Request Header.   I don't see anything in 5988 saying anything one 
> way or the other, but eg http://en.wikipedia.org/wiki/
> List_of_HTTP_header_fields puts it as a Response Header.
> 
> Do you think we could put it in At Risk, as see if IETF folks are 
> okay with it, as a Preference?

My "switch" from Link to Prefer was purely based on your "I[t] would be 
like a prefer header".
LDP *already* uses at least 1 Link header on requests (type=container on 
Create), so adding a second should not scare anyone any more.
If we make it a new preference, yes I imagine we'd do it at-risk, but all 
we need on the IETF side IIRC is an email for expert review of the 
registration ... I looked into this "fairly deeply" when we were on a path 
to do that earlier.
OTOH, if  we make it a new preference *parameter*, ala pagesize, there is 
no registration process AFAIK. 
What gets complicated is the granularity of the Preference-Applied 
response header, which is per-preference IIRC not per-preference-parameter 
(and it's optional, if the client can tell from the response whether or 
not the preference was applied).  So an implementation that supports paged 
containers but not sorting might have trouble figuring out how to respond 
to a paged+sorted request if we went the parameter route.  Thinking this 
case through, it should be unambiguous actually... we have type=ldp:Page 
and rel=canonical on pages, and we'd now have rel=sort-criteria (picking 
out of thin air) iff (sic) the members are sorted.

The only queasy bit this thread causes is caching.  We were pretty 
unconcerned about create requests having to add a cache-control: Link 
response header (or being uncachable), since most POSTs are not cached 
anyway (although they're eligible according to HTTP).  We might care more 
about this case, since it's "primarily" GETs.  It could be argued that 
implementers have to read the spec, and therefore have to add cache 
controls for whatever request headers we say they do, so on that basis 
alone Link vs Prefer is a wash.  Recall from the create discussion too 
that using Link on requests is low-risk today mostly *because* few 
requests have them; if that were to change tomorrow, our decision might 
affect the cacheability of more requests (non-LDP requests with Link 
headers) in an unintended way.  With Prefer return-representation's fairly 
clear treatment of caching, it might be that implementations are "more 
likely to get it (response caching) right" with Prefer.
There also would be nothing wrong btw in saying:
- request: Prefer [preference | return=representation with new parameter]
- response: Link rel=sort-criteria
Which basically uses each in pretty much the mainline way they were 
intended, based on all my reading and discussions.


Best Regards, John

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