Subject: [httpapi] Lars Eggert's No Objection on draft-ietf-httpapi-linkset-08: (with COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 01 Mar 2022 06:56:44 -0800

Lars Eggert 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:
----------------------------------------------------------------------

This document seems to have unresolved IANA issues.

(Francesca noted the DOWNREFs in her comment.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms "natively" and "native"; alternatives might be "built-in",
   "fundamental", "ingrained", "intrinsic", "original".

Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/CNdklatSYc9n39gTau8BGlECMio).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.1. , paragraph 4, nit:
>  format specified here is different than the "application/link-format" forma
>                                     ^^^^
Did you mean "different from"? "Different than" is often considered colloquial
style.

Section 5. , paragraph 4, nit:
> y profile information pertaining to a links set. 7.1. Set of Links Provided a
>                                     ^^^^^^^
The plural noun "links" cannot be used with the article "a". Did you mean "a
link" or "links"?

Reference [RFC5988] to RFC5988, which was obsoleted by RFC8288 (this may be on
purpose).

These URLs in the document can probably be converted to HTTPS:
 * http://www.w3.org/ns/json-ld#context
 * http://purl.org/dc/terms/title
 * http://purl.org/dc/terms/format
 * http://purl.org/dc/terms/language

---

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

hi Lars,

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

====

Response: fixed in the new version of the I-D

 * Terms "natively" and "native"; alternatives might be "built-in",
   "fundamental", "ingrained", "intrinsic", "original".
Response: fixed in the new version of the I-D

Thanks to Christer Holmberg for their General Area Review Team (Gen-ART)
review
(https://mailarchive.ietf.org/arch/msg/gen-art/CNdklatSYc9n39gTau8BGlECMio).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may
choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so
there
will likely be some false positives. There is no need to let me know what
you
did with these suggestions.

>  format specified here is different than the "application/link-format"
forma
Did you mean "different from"? "Different than" is often considered
colloquial
style.

Response: fixed in the new version of the I-D

Response: fixed in the new version of the I-D

Reference [RFC5988] to RFC5988, which was obsoleted by RFC8288 (this may be
on
purpose).

Response: yes, on purpose

Response: these are actual HTTP URLs, see e.g.
https://www.dublincore.org/specifications/dublin-core/dcmi-terms/

====

On Tue, Mar 1, 2022 at 3:56 PM Lars Eggert 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