Web Linking
draft-nottingham-rfc5988bis-08

[Ballot comment]
- Since this seems to be the week for this recurring controversy: I agree with Mirja that the abstract should mention that this obsoletes 5988.

2.1.1.1 and 2.1.1.2 seem to entirely contain IANA considerations. It seems a bit strange to specify them here and reference them from the IANA section. (I can accept this as a stylistic choice, but it creates additional work for anyone who came to this  draft primarily to learn the IANA bits.)

- 2.1.1.1: "The expert(s) MAY define additional fields to be collected in the
registry."
How should they go about doing that?

- 2.1.1.2: It seems like a mild abuse of the spirit of 2119 to put MUST and SHOULD requirements on the designated experts.

[Ballot comment]
ART and others are more qualified to make useful determinations here, so I'll restrict myself to nits. :-P

1: The Note to Readers should have an "RFC Editor, please remove" tag.

2: Section 2: " A link can be viewed as a statement of the form "_link context_ has a  _link relation type_ resource at _link target_, which has _targetattributes_". If possible, it would be really helpful to have an example here - this may be clear to those schooled in the arts, but I found this hard to parse, and required much flipping back and forth to understand.

[Ballot discuss]
Document: draft-nottingham-rfc5988bis-07.txt

  Link applications ought to consider the attack vectors opened by
  automatically following, trusting, or otherwise using links gathered
  from HTTP header fields.  In particular, Link header fields that use
  the "anchor" parameter to associate a link's context with another
  resource are to be treated with due caution.

I share Alan DeKok's concern here. Say I am a Web browser and I
get a link with an anchor tag, what goes in Referer?

[Ballot discuss]
As compared to RFC5988, there are some non-backwards-compatible syntax changes in this new document that can hamper interoperability between new implementations and old ones. These changes should at least be called out explicitly, and guidance given to maximize chances of interop with RFC5988 implementations. See comments, below, for details.

[Ballot comment]
Dropping the diff from RFC5988 in here for others' use:
https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/rfc/rfc5988.txt&url2=draft-nottingham-rfc5988bis-07

The document contains some modifications to IANA registration procedures, including:

    Note that relation types can be registered by third parties
    (including the expert(s)), if the expert(s) determine that an
    unregistered relation type is widely deployed and not likely to be
    registered in a timely manner otherwise.

It's not clearly stated that this note overrides the MUST-strength normative requirement to "reference a freely available, stable specification," although such is presumably the intention? If so, please make it very clear by stating that this third-party registration process is exempted from the normative requirement.

The new rules for syntax ('any "link-param" can be generated with values using either the "token" or the "quoted-string" syntax') are not backwards-compatible with RFC5988's definitions of anchor and hreflang (where the syntax of the former requires quotes, and the syntax of the latter forbids them). I'm sure this potential breakage was carefully evaluated, and the benefits were found to outweigh the potential drawbacks; however, I'm surprised that the document does not call out this situation explicitly. Please add text that at least points out that these two parameters had previously been defined in a more strict fashion, and maybe an indication that implementations wishing to maximize interoperability should quote titles, and omit quotes from hreflang.

Along these lines, please update the associated ABNF to reflect this new syntax rule; e.g., hreflang should be:

  Language-Tag | <"> Language-Tag <">

Speaking of which -- we have ABNF for all parameters except "title" and "title*". Was this omission intentional? It seems odd.

[Ballot comment]
Processing comments:
- The abstract should say that this document obsoletes RFC5988
- I don’t think we need to keep the pre-5378 disclaimer given Mark the only author of rfc5988 as well

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-nottingham-rfc5988bis-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

The entry for Link (http) will have its reference changed to [ RFC-to-be ].

Second, in the Link Relation Types registry on the Link Relations registry page located at:

https://www.iana.org/assignments/link-relations/

the authors have requested a change to the Expert Review and registry management procedures for the registry. The IANA Services Operator is reviewing the instructions in Section 4.2 and may need to discuss the details with the author. Until there is confirmation of these details, please do not move forward with the document.

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

1. Summary

Barry Leiba is the document shepherd; Alexey Melnikov is the responsible AD.

This specification defines a model for the relationships between
resources on the Web ("links") and the type of those relationships
("link relation types").  It also defines the serialisation of such
links in HTTP headers with the Link header field.  This is a revision of
RFC 5988, and obsoletes that document.

2. Review and Consensus

This is mostly a piece of work that needed to get done but that no one
had much interest in doing.  Mark took it on and got feedback, but the
document shepherd can't find any record of discussion in any mailing
list archives.  Mark brought it to DISPATCH, which raised no interest
either.

There was a good amount of discussion on the github issues list, which
had good representation from the community:
  https://github.com/mnot/I-D/issues?q=is:issue label:rfc5988bis

The bottom line is that the document is ready to go, and any last-call
discussion will be adequate.  This is a good example of a document for
which silence  is a reasonable measure of consensus.  The only tricky
bit is that Section 4.2 is proposing a different model for maintaining
the registry, and we need to make sure there's good communication with
IANA on that.

3. Intellectual Property

The author is in full compliance with BCPs 78 and 79.  There are no IPR
statements related to RFC 5988 nor to this replacement.

4. Other Points

This document depends upon 5987bis, which is in the RFC Editor queue.

This document inherits the pre-5378 disclaimer from RFC 5988.

As mentioned in section 2 above, the Section 4.2 of the document
proposes a significant difference to normal registry management.  The
proposed change makes sense for the community the registry is intended
for, and it will be important to check the IANA reviews and to discuss
the requested changes with IANA during last call.

1. Summary

Barry Leiba is the document shepherd; Alexey Melnikov is the responsible AD.

This specification defines a model for the relationships between
resources on the Web ("links") and the type of those relationships
("link relation types").  It also defines the serialisation of such
links in HTTP headers with the Link header field.  This is a revision of
RFC 5988, and obsoletes that document.

2. Review and Consensus

This is mostly a piece of work that needed to get done but that no one
had much interest in doing.  Mark took it on and got feedback, but the
document shepherd can't find any record of discussion in any mailing
list archives.  Mark brought it to DISPATCH, which raised no interest
either.

The bottom line is that the document is ready to go, and any last-call
discussion will be adequate.  This is a good example of a document for
which silence  is a reasonable measure of consensus.  The only tricky
bit is that Section 4.2 is proposing a different model for maintaining
the registry, and we need to make sure there's good communication with
IANA on that.

3. Intellectual Property

The author is in full compliance with BCPs 78 and 79.  There are no IPR
statements related to RFC 5988 nor to this replacement.

4. Other Points

This document depends upon 5987bis, which is in the RFC Editor queue.

This document inherits the pre-5378 disclaimer from RFC 5988.

As mentioned in section 2 above, the Section 4.2 of the document
proposes a significant difference to normal registry management.  The
proposed change makes sense for the community the registry is intended
for, and it will be important to check the IANA reviews and to discuss
the requested changes with IANA during last call.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, barryleiba@computer.org, draft-nottingham-rfc5988bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Web Linking) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Web Linking'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines a model for the relationships between
  resources on the Web ("links") and the type of those relationships
  ("link relation types").

  It also defines the serialisation of such links in HTTP headers with
  the Link header field.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-nottingham-rfc5988bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-nottingham-rfc5988bis/ballot/


No IPR declarations have been submitted directly on this I-D.