Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

[Mario Loffredo <[e-mail]>]

Hi Tom,

my comments are inline.

Il 22/04/2022 06:16, Tom Harrison ha scritto:
> 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.
[ML] OK. I'll remove the references to JSContact from this document and 
I'll add text to rdap-jscontact to clarify the mapping from both search 
(including reverse search) properties and sorting properties to 
JSContact fields.
>>>       - 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.
[ML] I have no objection to add in this document the following optional path

{searchable-resource-type}/reverse/{related-resource-type}/metadata


      {
        "rdapConformance": [
          "reverse_search_0"
        ],
        "reverse_search_properties": [
          {
            "name": <reverse search property name>,
            "rdapProperty": <RDAP property path>
          }
        ]
      }


Do you agree?
>
>>>    - 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?

[ML] Sounds me good.

Best,

Mario

>
> -Tom

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo