Subject: [httpapi] Éric Vyncke's No Objection on draft-ietf-httpapi-linkset-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 01 Mar 2022 23:12:43 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-httpapi-linkset-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. As I added recently "Link:" to
some web properties for HTTP/2 "push", I understand the usefulness of this
specification.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Rich Salz for the shepherd's write-up including the section
about the WG consensus even if I regret the absence of intended status
justification (even if there is a brief history of the intended status).

I hope that this helps to improve the document,

Regards,

-éric

As other ADs have noted, I am really puzzled by having two ways to format the
same information. The Figures 8 & 10 examples try to explain that when
delivering a format there could be a link to the other format, but I find this
really weird.

Is there a performance impact when using a different document rather than the
Link: in the HTTP header. Does it mean that the web server (Apache, nginx) has
also to parse the HTML content and not only the Link: to push content over
HTTP/2 ?

## Section 4.2.3

Please use https://example.net rather than http://example.net

## Section 7.3

What is the logic of including the linkset in a Link: header while previous
justification of this specification was that some applications cannot generate
Link: header?

## Section 9

I trust the security ADs for a careful review but the 3rd party links seems an
open door for a DoS if a popular site starts to advertise links to a 3rd party
large ressource... The 3rd party then becomes then a victim.

# NITS

## Section 7.4.2
Please align Figure 16 with the text (possibly a xml2rfc bug).

---

From: Herbert Van de Sompel <[email-masked]>
Date: Tue, 8 Mar 2022 12:36:12 +0100

hi Éric,

Your comments were addressed either by edits to the I-D or by feedback
provided below under "Response". New I-D version at
https://github.com/ietf-wg-httpapi/linkset/blob/master/draft-ietf-httpapi-linkset-09.xml

Greetings

Herbert

==========

As other ADs have noted, I am really puzzled by having two ways to format
the
same information. The Figures 8 & 10 examples try to explain that when
delivering a format there could be a link to the other format, but I find
this
really weird.

Response: The motivation for having two formats is that one provides
compatibility with existing use of Web Linking (i.e. links in HTTP Link)
and the other caters to the massive cohort of developers that use JSON. We
expect respective communities of practice to settle on a single format,
maybe depending on whether or not they already use HTTP Link. If
communities support both, they can brag about this by linking to another
format.

Is there a performance impact when using a different document rather than
the
Link: in the HTTP header. Does it mean that the web server (Apache, nginx)
has
also to parse the HTML content and not only the Link: to push content over
HTTP/2 ?

Response: Not sure I understand the question because there is no HTML
involved. Also, I'm not familiar with HTTP/2 push.

## Section 4.2.3

Response: Fixed in the I-D

## Section 7.3

What is the logic of including the linkset in a Link: header while previous
justification of this specification was that some applications cannot
generate
Link: header?

Response: Because in many cases a Link header can be generated

## Section 9

I trust the security ADs for a careful review but the 3rd party links seems
an
open door for a DoS if a popular site starts to advertise links to a 3rd
party
large ressource... The 3rd party then becomes then a victim.

Response: Caution is expressed in the I-D about 3rd party links

# NITS

## Section 7.4.2

Response: Fixed in the I-D

===========

On Wed, Mar 2, 2022 at 8:12 AM Éric Vyncke via Datatracker <[email-masked]>
wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> --
> httpapi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpapi
>

-- 
==================
Herbert Van de Sompel
https://hvdsomp.info
https://orcid.org/0000-0002-0715-6126