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?
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.
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.
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.
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.
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
--
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
