A question about LDPR, LDP-RS, and rel="type" Link headers

Hi,

IIRC, in the previous LC, we had binary/text (non-RDF) resources as
non-LDPRs but we decided to move to in to the hierarchy by giving them the
name LDP-NR and making them a subclass of LDPR.

But this has some implications on the previous restrictions. For instance,

*4.2.1.4 LDP servers exposing LDPRs must advertise their LDP support by
exposing a HTTP Link header with a target URI of
http://www.w3.org/ns/ldp#Resource <http://www.w3.org/ns/ldp#Resource>, and
a link relation type of type (that is, rel='type') in all responses to
requests made to the LDPR's HTTP Request-URI.*

IIRC, in the previous last call we only send this header for only LDP-RS
and not for LDP-NR (because they were at the time non-LDPR).

Then in the same point, we say

*The presence of this header asserts that the server complies with the LDP
specification's constraints on HTTP interactions with LDPRs, that is it
asserts that the resource has Etags, has an RDF representation, and so on,
which is not true of all Web resources served as RDF media types.*

Was this intentional ? In that case, do we need to have two separate values
identify the two types like we do in containers ?

Talking about containers, I think in the example 8, the Link header should
be
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type" instead of
Link: <http://www.w3.org/ns/ldp#Container>; rel="type".

Also regarding the Link header, in 5.2.1.4 we say 'The notes on the
corresponding LDPR constraint apply equally to LDPCs.'. So does this mean a
container should always advertise two Link headers, e.g.

Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#Container>; rel="type"

I find it a bit redundant as LDPC is a subclass and always a LDP-RS/LDPR
but not an issue. Just wanted to make sure as I don't remember all the
discussions on client inference vs overhead.

Best Regards,
Nandana