Hi Mario,
On Thu, Apr 21, 2022 at 04:51:15PM +0200, Mario Loffredo wrote:
> thinking back to my last message, I need some clarifications before
> updating the document.
>
> Please find my comments inline.
>
> Il 18/04/2022 13:10, Tom Harrison ha scritto:
>> - I-D.ietf-calext-jscontact is listed as an informative reference,
>> but it appears to be a normative reference, given that the
>> JSONPaths for 'fn' and 'email' are taken from that document.
>> Assuming that it is a normative reference, then it may be that the
>> reverse search document will be approved notwithstanding the
>> downref. However, there are a couple of options for avoiding that
>> in the first place:
>> - Define the document in terms of jCard only, and note that
>> documents defining successor formats to jCard will describe how
>> to handle the conversion from 'fn'/'email' to the corresponding
>> fields in the new format.
>
> [ML] Note a different feeling about it between you and Scott. I
> mostly agree with you on this point but I'm open to any solution
> that is shared by the WG, especially if it comes from those having
> long experience in writing IETF documents.
I'm not sure there is much difference between the suggestion above and
the one originally made by Scott, since he noted that updating the
JSContact draft was one possible way to deal with his concern. More
generally, JSContact may need further text on this topic to deal with
things like the base entity search defined in RFC 9082, which is in
terms of "the 'fn' property of an entity" (at least, I couldn't see an
update for this in the JSContact document when I looked at it), so
that may be another consideration in favour of centralising this type
of update in that document.
>> - Define inline metadata, so that the relevant JSONPaths are
>> available to the client, and can be changed to work for
>> JSContact when a server switches to use JSContact (similarly to
>> how things work with RFC 8977).
>
> [ML] I have already proposed to extend the response with an inline metadata
> about the supported reverse search properties but I'm not sure when it
> should be returned.
>
> The metadata described in both RFC8977 and RFC 8982 include information
> about server features that can be applied to every search response,
> including reverse search.
>
> On the contrary, it wouldn't make sense to me to return the reverse search
> metadata in every search response.
To avoid any doubt, I'm not advocating for including metadata in this
document, but I think having a separate/standalone URL path for
retrieving the reverse search metadata would be a reasonable way to
handle this.
>> - Section 2.1 has "Servers MAY implement other properties than those
>> defined in this section". A server that supports other properties
>> for the purposes of reverse search has no way to indicate that
>> support except by way of a standards-track specification that
>> defines a new rdapConformance value, which would be the case
>> regardless of this additional text in the document, so it seems
>> like this text could be omitted.
>
> [ML] Most probably I didn't make myself clear. I meant that servers
> may implement additional reverse search properties, including those
> mapped to RDAP response extensions.
>
> Just to give you an example, some ccTLDs, including .it, have
> extended the registrant information with the tax code.
>
> Being such a code a unique identifier, it could be eligible as
> reverse search property.
>
> Don't think servers should specify a specific RDAP conformance tag
> in that case. It would be enough for them to provide the reverse
> search properties they implement in the /help response.
I don't think this is the case. Documenting protocol behaviour in the
help response in a way that's not able to be processed interoperably
is not ideal, especially considering that the rdapConformance field
exists so as to avoid having to do this sort of thing. Additionally,
having server operators implement reverse search for core RDAP fields
in the absence of a specification might lead to divergent behaviour
(there's probably a low chance of this, but still). However, this
second consideration doesn't affect fields defined in extensions, and
if the extension author is fine with documenting support for reverse
search in the extension, that avoids both problems, so maybe the
following text would be sufficient:
A server that includes additional fields in its objects in
accordance with the extensibility provisions of section 6 of RFC
7480 MAY support the use of those fields in search conditions, in
the same way as for the search conditions defined in this document
(in section 2.1). Support for such fields in the reverse search
context MUST be documented in the extension specification.
What do you think?
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
