paging in editor's draft

I mentioned on the call today some early feeback from EricP.
In addition to the 2 typos that I'm fixing, this is more substantive:
EricP>  I thing we voted on last and prev being a package, i.e.:
EricP> LDP servers that serve a last page link MUST provide and HTTP 
<code>Link</code>

I'm not clear on the WG's intent here.  I don't care either way, it's just 
unclear from the minutes and emails what the intent is/was.
In both his amended proposal [1] and the original [2], he used a term 
"doubly linked servers".  From the feedback above, it's possible that his 
intent was:
- two classes of servers, in terms of the paging links
- all provide first+next
- only "doubly linked" ones provide prev+last

In the approved proposal [2], "doubly-linked servers" was used without 
definition.  I (obviously?) did not draw the conclusion that the linkage 
above exists.  I have zero problem writing it that way, I just want to be 
sure that all in the WG (even if that's "aside from me") have the same 
understanding.
If anyone objects to Eric's interpretation, speak up and we can hash it 
out on the mailing list (and if necessary, get it on the meeting agenda). 
If I see no objections by Friday, I'll align the draft with that.

Since I'm here anyway, one further note: as detailed in the action [3], I 
drafted changes to align with the amended proposal [2] (adds link 
rel=collection) AND generalized it so that it CAN apply to resources other 
then LDPRs (any HTTP resource, now, although LDP only says how LDPR pages 
could be combined for re-form [a potentially incomplete copy of] the paged 
resource's state).

[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0081.html
[2] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0055.html
[3] http://www.w3.org/2012/ldp/track/actions/105

Best Regards, John

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