Jasdip, Tom, Happy new year, and thank you for your replies.
The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9910.html https://www.rfc-editor.org/authors/rfc9910.txt https://www.rfc-editor.org/authors/rfc9910.pdf https://www.rfc-editor.org/authors/rfc9910.xml This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9910-diff.html https://www.rfc-editor.org/authors/rfc9910-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9910-auth48diff.html https://www.rfc-editor.org/authors/rfc9910-auth48rfcdiff.html (side by side) To follow up: - Re: #1, any keywords that you would like to add for use on the search page (https://www.rfc-editor.org/search)? - Re: #4, the last sentence of Section 3.4 remains as in the original, per your preferences. - Re: the request for 10.1 and 10.2, this would lead to odd placement of the URL in the text output (shown below), so the change has not been made. Including the word 'registry' in the hyperlink is our preference, and 10.3 and 10.4 have been updated accordingly. Jasdip wrote: > In section 10.1, for the hyperlinked ""RDAP Extensions” registry” phrase, the > word “registry” should not be hyperlinked. > > Similarly, in section 10.2, for the hyperlinked ""Link Relations” registry” > phrase, the word “registry” should not be hyperlinked. That would yield the following in the text file: IANA has registered the following values in the "RDAP Extensions" <https://www.iana.org/assignments/rdap-extensions> registry. IANA has registered the following values in the "Link Relations" <https://www.iana.org/assignments/link-relations> registry. An alternative would be to add an informative reference for each, e.g., 'in the "RDAP Extensions" registry [RDAP-EXTENSIONS]'. If you prefer that option, please let us know. We will wait to hear from you again before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9910 Thank you. Alice Russo RFC Production Center > On Dec 23, 2025, at 3:00 PM, Tom Harrison <[email protected]> wrote: > > 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 > On Dec 26, 2025, at 8:49 AM, Jasdip Singh <[email protected]> wrote: > > Hi Alice, > > For consistency, the phrases in tables 1 and 2 should also be uppercased: > “Parent Objects” for the former and “Child Objects” for the latter. > Similarly, "Example Single-Result Links in an IPv6 Response” for Figure 7. > > Thanks for honing this specification. :) > > Jasdip > > From: Jasdip Singh <[email protected]> > Date: Tuesday, December 23, 2025 at 4:57 PM > To: [email protected] <[email protected]>, [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9910 <draft-ietf-regext-rdap-rir-search-19> > for your review > > Hi Alice, > > Sorry, missed couple… Please also make the following changes, if possible: > > In para 2 of section 1.1, for consistency with previous RDAP specs, replace: > > "Indentation and whitespace in examples are provided only to illustrate > element relationships, and they are not a required feature of this protocol.” > > with: > > "Indentation and whitespace in examples are provided only to illustrate > element relationships and are not required features of this specification.” > > In section 10.1, for the hyperlinked ""RDAP Extensions” registry” phrase, the > word “registry” should not be hyperlinked. > > Similarly, in section 10.2, for the hyperlinked ""Link Relations” registry” > phrase, the word “registry” should not be hyperlinked. > > Thanks, > Jasdip > > > From: Jasdip Singh <[email protected]> > Date: Tuesday, December 23, 2025 at 3:48 PM > To: [email protected] <[email protected]>, [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9910 <draft-ietf-regext-rdap-rir-search-19> > for your review > > Hi Alice, > > Please see my comments inline, marked [JS]. > > Thanks, > Jasdip > > From: [email protected] <[email protected]> > Date: Monday, December 22, 2025 at 1:42 PM > To: [email protected] <[email protected]>, Jasdip Singh <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9910 <draft-ietf-regext-rdap-rir-search-19> > for your review > > <snip> > > > 2) <!--[rfced] search response vs. response code vs. response > > The original uses various terms ("search response" and "response code" > and "response") after an HTTP status code. Would you like to update > "search response" to "response code" to match 2 instances in this document > or "status code" to match the cited document (RFC 9110) or otherwise? > For example: > > Original: ... with a HTTP 404 (Not Found) [RFC9110] search response. > Option A: ... with an HTTP 404 (Not Found) [RFC9110] response code. > Option B: ... with an HTTP 404 (Not Found) [RFC9110] status code. > —> > > [JS] Option B. > > > 3) <!-- [rfced] In Figure 5, two lines are longer than the line limit. > To resolve this, is moving the two lines to the left as shown below > acceptable? If not, please provide your preferred solution. > > -19.xml(940): Warning: Too long line found (L677), 1 characters longer than > 72 characters: > ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active", > -19.xml(940): Warning: Too long line found (L684), 2 characters longer than > 72 characters: > ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active", > > Current: > "href": > ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active", > [...] > "href": > ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active", > > Perhaps: > "href": > ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active", > [...] > "href": > ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active", > —> > > [JS] OK. > > > 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. > —> > > [JS] 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”. > > 5) <!-- [rfced] Please review whether the "type" attribute is set as > intended for sourcecode elements in the XML file. If the current list > of preferred values for "type" > (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not > contain an applicable type, then feel free to suggest a new one. > Also, it is acceptable to leave the "type" attribute not set. > > FYI, in Figure 8 (IPv4 Network Search Response) and similar, we changed > sourcecode type="drawing" to type="json", as "drawing" is not a type > of sourcecode - and because of usage in STD 95 (on the intake form, > you wrote to follow STD 95): we see RFC 9083, Figure 32 contains a > search response in sourcecode with type="json" > (https://www.rfc-editor.org/rfc/rfc9083.html#figure-32). > Please let us know if you prefer otherwise. > —> > > [JS] OK. > > 6) <!--[rfced] For clarity, may this be rephrased? > Specifically, may "for" be changed to "that of" in > "the behaviour of the lookup URL is the same as for the search URL"? > Regarding "is the same as for the search URL as at the time when": > - The use of "as" twice in this phrase is unclear. > - "at the time when" is redundant. (Suggest removing "when".) > Please review whether the suggested text conveys the intended meaning. > > Original: > When using a link object for a single-result search, a server may > replace a search URL with a lookup URL, because the behaviour of the > lookup URL is the same as for the search URL as at the time when the > response is generated. > > Perhaps: > When using a link object for a single-result search, a server may > replace a search URL with a lookup URL, because the behaviour of the > lookup URL is the same as that of the search URL at the time the > response is generated. > —> > > [JS] OK, that reads better. > > 7) <!-- [rfced] FYI, we updated "Whois" to "WHOIS" (2 instances) to > match the cited RFC - [RFC3912] - as well as usage in STD 95. Please > let us know if you prefer otherwise. > —> > > [JS] OK. > > <snip> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
