Client MUST advertise ability to support LDP Paging

The Editor's Draft contains the following paragraph:

6.2.17 LDP Paging servers must not initiate paging unless the client has
indicated it understands paging. The only standard means defined by LDP
paging for a client to signal a server that the client understands paging
is via the client preference defined for this purpose; other
implementation-specific means could also be used.

Non-normative note: LDP Paging servers could choose to make any resource
available only as a paged resource. One consequence of the prohibition on
initiating paging when interacting with non-paging-aware clients is: if
such a server receives a request for a paged-only resource, and the request
does not signal that the client is paging-aware, then the server has to
reject the request, most likely with a 4xx status code. This avoids the
situation where a non-paging-aware client blindly follows a 303 redirect,
retrieves that resource (which the server, but not the client, knows to
contain only the first page of the paged resource's state), and upon
receiving the 200 OK status code concludes that it now has the entire
representation of the paged resource's state (instead of only having a
representation of the subset assigned to the first page).

The rationale provided in the non-normative note indicates that the
conformance rule exists so that clients won't mistakenly assume that they
have received the complete state of a resource.  But RDF is based on the
open world assumption, so clients can never assume that they have the
complete state of a resource.

It seems to me that it may be worse to reject the request entirely with a
4xx status code.  The average web developer uses paging all the time
without these kinds of strictures.  I worry that this conformance rule will
be a barrier to adoption of LDP Paging by those who want to build systems
that appeal not only to the semantic web community, but also the wider
community of web developers.

Regards,
Greg McFall