remove references to the deprecated `rev` link-param

[gabesullice]

This is in reference to the linkset draft:

RFC 8288 deprecated the rev link parameter in link header serializations.

Instead of explaining that a link can be "reversed" by making a reference to rel and rev, could the draft instead just call out that a the anchor and href can be swapped to represent a link in the "reverse" direction?

[hvdsomp]

This from version 4 of the Internet Draft:

Note that the JSON representation does not use the "rel" or "rev" constructs used by [RFC8288] and the above specified HTTP Link document format. Rather:

o A link that uses the "rel" construct in those approaches is conveyed using the URI of the link context as the value for "anchor" and the URI of the link target as the value for "href".

o A link that uses the "rev" construct in those approaches is conveyed using the URI of the link target as the value for "anchor" and the URI of the link context as the value for "href".

[gabesullice]

Correct. However, RFC 8288 deprecates the rev parameter:

rev is deprecated by this specification because it often confuses authors and readers; in most cases, using a separate relation type is preferable.

So, it's inaccurate to say "the rel or rev constructs used by [RFC8288]" since RFC 8288 specifically deprecates the rev construct.

To acknowledge that fact, I was suggesting that the language from the draft that you copied here be removed.

Instead, I would add a scenario along these lines:

In some cases, it is useful that links are given both from a context resource to a target resource and also from the original target resource back to the original context resource. In other words, it can be useful to represent a bidirectional link.

In such cases, the first link can be serialized normally and the reversed link can be serialized by giving the URI of the original target as a link anchor and giving the URI of the original link context as the link href.

[hvdsomp]

Addressed this in the I-D.