Thanks, Roberto, for considering my comments. The minor change to "first occurrence" clears up my question, and everything else looks good too. Barry On Wed, Apr 12, 2023 at 11:35 AM Roberto Polli <robipolli@xxxxxxxxx> wrote: > > Dear Barry, > > Thanks for your feedback. Replies inline. > I'm tracking all the points in > https://github.com/ietf-wg-httpapi/mediatypes/issues/80 > > On Tue, 28 Mar 2023 at 09:41, Barry Leiba via Datatracker > <noreply@xxxxxxxx> wrote: > > > > Reviewer: Barry Leiba > > Review result: Ready with Nits > > > > Thanks for this. I have a few comments, but they're all very minor: > > > > — Section 1.2.1 > > > > If multiple nodes would match a fragment identifier, the first such > > match is selected. > > > > I don’t know what “first” means here — alphabetically first, sequentially first > > in a set, something else? Is this clear enough for someone who actually uses > > YAML, or can/should it be clarified? > > The spec intends the first occurrence found while processing the unicode stream. > Do you think that the following sentence is ok? > > | If multiple nodes would match a fragment identifier, > | the first occurrence of such match is selected. > > > — Section 2.1 — > > > > Optional parameters: N/A; unrecognized parameters should be ignored > > > > Maybe “unrecognized parameters are ignored” ? > > Ok. PR made. > > > — Section 2.2 — > > > > The suffix +yaml MAY be used with any media type whose representation > > follows that established for application/yaml. > > > > This strikes me as a “may”, not a “MAY”. > > > > > > > Fragment identifier considerations: Differently from application/ > > yaml, there is no fragment identification syntax defined for > > +yaml. > > > > “Differently from” isn’t proper English here. I think you want “Unlike”. > > Ok. PR scheduled once we move the registration section in the IANA. > > > > — Section 3.5 — > > > > Implementers need to consider that the YAML version and supported > > features (e.g. merge keys) can impact on the generation of the > > representation graph (see Figure 9). > > > > The phrase “impact on” is non-standard English; please consider “affect” > > instead. > > Ok. PR made. > > > > — Section 4.2 — > > > > YAML documents are rooted, connected, directed graphs and can contain > > reference cycles, so they can't be treated as simple trees (see > > Section 3.2.1 of [YAML]). An implementation that attempts to do that > > can infinite-loop traversing the YAML representation graph at some > > point, for example: > > > > I find the antecedent to “do that” to be unclear, and using “infinite-loop” as > > a verb seems odd. I suggest this: > > > > NEW > > An implementation that treats them as simple trees risks going into an > > infinite loop while traversing the YAML representation graph. This > > can happen: > > END > > Ok. PR made. > > > > — Section 5 — > > > > IANA has updated the "Media Types" registry at > > https://www.iana.org/assignments/media-types > > (https://www.iana.org/assignments/media-types) with the registration > > information provided below. > > > > I presume the duplication of the URI is an artifact of the markup. But IANA > > has not, in fact, made these updates yet (I looked). > > You are right. We used the text contained in > https://www.rfc-editor.org/rfc/rfc9110#name-media-type-registration > > > I suggest “IANA is asked > > to update…”, and the RFC Editor will change this when they have confirmed that > > IANA has taken the requested actions. (This situation occurs twice in Section > > 5.) > > Ok. > > Thanks again for your review, > R. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
