Hi Alice, Thanks for your work on this document. I agree with each of Jasdip's comments. See inline for further comments.
On Tue, Dec 23, 2025 at 08:48:06PM +0000, Jasdip Singh wrote: > On Mon, Dec 22, 2025 at 10:35:21AM -0800, [email protected] wrote: >> 4) <!--[rfced] For clarity, how may this be rephrased? >> Specifically, please clarify "not necessarily mean". Does this mean >> it can go either way (results or no results)? The original is of >> the form "the absence of X does not necessarily mean that Y >> will return no results". >> >> Original: >> The absence in >> a response of a link for a specific relation does not necessarily >> mean that the corresponding search will return no results. >> >> Option A (using "may or may not"): >> In a response, the absence of a link for a specific relation may >> or may not mean that the corresponding search returns zero results. >> >> Option B (using "may or may not", and "cause" instead of "mean"): >> In a response, the absence of a link for a specific relation may >> or may not cause the corresponding search to return zero results. >> —> > > Would prefer to keep the original text since "does not necessarily > mean" connotes that one should not assume “no results” because of > “absence … of a link”. To elaborate on this: - Option A implies that the absence of a link has some deterministic bearing on whether the corresponding search returns results, at least on a per-server basis. That may be the case for some servers, but it's open to a server e.g. simply to omit all such links, in which case nothing can be inferred from their absence. - Option B implies that the absence of the link has some causal relationship on whether the corresponding search returns results, so it has a similar problem. Per Jasdip's comments, I prefer the original here, but some possible alternatives: - Since the use of these link relations is optional, a client cannot infer from the absence of a link with a given relation that the corresponding search will return no results. - Since the use of these link relations is optional, the absence from a response of a link with a given relation is not a basis for inferring that the corresponding search will return no results. > 8) <!-- [rfced] Please review the "Inclusive Language" portion of > the online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for > readers. > > For example, please consider whether the following should be > updated: > whitespace > --> Just to avoid any doubt, I'm not aware of an alternative term that could be used here, and it was also used in the same way in e.g. RFC 9877. One other change: * Section 3.2.1 OLD: The relationships of INR object value to parent object (as well as to child objects) are: NEW: For this example registry, the INR object value to parent/child object relationships are: Comment: I'd prefer that this text be more clearly linked to the example registry, so that there's no potential confusion as to what it's referring to if a reader looks at the text in isolation. In OLD, the fact that the child object relationship text is in a parenthetical could be read as implying that it is somehow subordinate or secondary to the parent object relationship text, so I'd prefer that the text be adjusted to be more like the original in this respect. -Tom -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
