Re: [Last-Call] [httpapi] Genart last call review of draft-ietf-httpapi-linkset-06

[Christer Holmberg <christer.holmberg=40ericsson.com@xxxxxxxxxxxxxx>]

Hi Herbert,

 

Thanks for the reply! Please see inline

 

(I wasn’t sure whether you wanted by reply by e-mail, or in GitHub, so I send it by e-mail).

 

---

>Q1: The I-D went through the HTTPAPI WG tagged as intended to be published as an Informational RFC. It do not remember suggestions to
>go down a different path. Maybe @richsalz @darrelmiller have an opinion on whether or not Informational is inappropriate?

The reason I ask is because the definition of Information says:

   “An "Informational" specification is published for the general

   information of the Internet community, and does not represent an

   Internet community consensus or recommendation.”

To me the draft is a little more than a “specification published for the general information of the Internet community”.

I guess IESG will decide whether Informational is appropriate. To me it sounds strange, and that’s the reason I asked :)

---

>Q2: The I-D defines the application/linkset+json media type and leverages an established technique (provision of context as per as per Section 6.8 of the W3C JSON-LD
>Recommendation(https://www.w3.org/TR/2014/REC-json-ld-20140116/#interpreting-json-as-json-ld) to allow that JSON to be interpreted as JSON-LD. This approach allows
>communities of use to specify a context that best serves their needs and does not require imposing specific vocabularies.

Perhaps it would be useful to have some text explaining that.

Also, I assume that an entity that supports the media type is not required to support JSON-LD, so maybe explicitly clarifying that too?

---

>Q3: Yes, the sentence you suggest would work, although the "based on the syntax" bit might be interpreted as "that syntax with a few twists". I feel that the
>existing sentence does not leave such room for interpretation. A matter of preferred style, I guess.

If the syntax is identical, you could say something like ”using the syntax of the Link header field”.

In any case, it is just editorial, so whatever you prefer :) However, please verify that you use the same terminology throughout the document.

---

>Q4: The term document format doesn't sound quite appropriate, indeed. I suggest replacing the sentence:
>
>Therefore, this specification defines two document formats that serialize Web Links and their attributes.
>
>by the following sentence that matches the terminology used in the Abstract:
>
>Therefore, this specification defines two document formats for representing sets of Web Links and their attributes as stand-alone documents.

Your new text looks better :)

However, my comment was regarding having a reference for “document”. For example, is it different than “payload format”, which is often used?

---

>Q5: I suggest replacing the sentence:
>
>One serializes links in the same format as used in HTTP the Link header field, and the other as a JSON object.
>
>by:
>
>One serializes links in the same format as used in HTTP the Link header field, and the other serializes links in JSON.

Looks good.

Regards,

Christer

 

 

 

On Tue, Jan 11, 2022 at 12:27 AM Christer Holmberg via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Christer Holmberg
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpapi-linkset-06
Reviewer: Christer Holmberg
Review Date: 2022-01-10
IETF LC End Date: 2022-01-19
IESG Telechat date: Not scheduled for a telechat

Summary: Technically I don't have any major issue.  However, I do have a minor
technical, one administrative, and some editorial, comments.

Major issues:

Q1: The draft is intended to be published as Informational RFC. That sounds a
little strange to me. Could you please explain what the reason is?

Minor issues:

Q2: The document defines the "application/linkset+json" format, and indicates
that it can also be used for JSON-LD. What is the reason for not defining a
separate format for JSON-LD? Separate formats ("application/json" and
"application/ld+json") have previously been defined.

Nits/editorial comments:

Q3: The document has long sentences like "One serializes links in the same
format as used in HTTP the Link header field". Couldn't one just say "based on
the syntax of the HTTP Link header field", or something like that?

Q4: The document talks about "document format". People familiar with HTTP are
probably familiar with that terminology, but I think it would be good to add a
reference on first occurrence.

Q5: In Section 1, you talk about serializing links as JSON objects. Should it
be JSON strings, or something? JSON object is not a serialization.


--
httpapi mailing list
httpapi@xxxxxxxx
https://www.ietf.org/mailman/listinfo/httpapi

--

==================

Herbert Van de Sompel

https://hvdsomp.info

https://orcid.org/0000-0002-0715-6126

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call