For a link in the HTTP Link header, the following holds:

• If the link has no anchor, then the URI of the resource that delivered the HTTP Link header (responding resource) is the anchor
• If the link has an anchor and its value is a relative URI, then the URI of the resource that delivered the HTTP Link header (responding resource) is the baseURI for the anchor

Applying the above to a linkset yields:

• If a link in a linkset has no anchor, then the URI of the link set resource (resource that delivered the linkset) is the anchor
• If a link in a linkset has an anchor and its value is a relative URI, then the URI of the link set resource (resource that delivered the linkset) is the baseURI for the anchor

The current linkset I-D has explicit cautionary language with this regard, anticipating that the above behavior is most likely not what implementers would want to achieve.

In addition, contrary to a typical use of links in an HTTP header (follow your nose during an HTTP navigation session), links in a link set may be used in a standalone manner, meaning disconnected from the link set resource that - as per the above - is supposed to provide URI/baseURI for anchors. In such standalone uses, the information about the link set resources that provided the linkset may no longer be available. As such, it would be good if linksets would be self-contained, i.e. be explicit with regard to what the anchor of each link is.

The above tries to make the point that it would be beneficial to simultaneously:

• Avoid the risk of misinterpretation of link anchors, which is warned for by explicit language in the I-D
• Make linksets self-contained regarding link anchors

I see two possible approaches:

1. Require that each link in a linkset has an anchor with an absolute URI
2. In serializations, require an information element similar to BASE in HTML to express a BaseURI for link anchors

Note that (2) could be achieved in JSON, especially when following proposal #103 by @BigBlueHat, which is the plan. But, it could not be achieved for the application/linkset serialization since it is a direct mapping of the Link header syntax.