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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
