Hi Andy,
thanks a lot for your review and feedback.
Please find my comments below.
Il 16/03/2023 15:24, Andrew Newton ha scritto:
Hi all,
I'm doing some RDAP programming and looking at the JSContact draft and
have a couple of comments.
1) Section 3 has some strong MUST language regarding JSContact and
EPP. As I'm reading it, I am trying to deduce what interoperability
problem is being mitigated but, at least to me, it is not apparent. If
there is some cardinality issue, I think the rules should be
generalized because RDAP is used by more than just the EPP registries,
most notably the RIRs but also Marc's space debris proposal.
If an EPP mapping is truly necessary, I think putting it in a separate
EPP mapping section would be better. Also, unless things will truly
break, the normatives should be SHOULD and not MUST.
[ML] No problem. I can remove the reference to the RFC5733 labels and
generally talk about the unique or the preferred value for each contact
property.
I would be inclined to leave MUST to provide clients and servers with a
pre-defined set of map keys for the mostly used contact properties.
In addition, I would define a general mapping scheme that SHOULD
(instead of MAY) be used for the additional entries of the mostly used
maps or others.
The scheme could merely consist in appending a sequential number to the
map name in the singular (e.g. "phone-1", "phone-2" for the additional
entries of the "phones" map to those identified by "voice" and "fax" ).
The other option is to always apply the general scheme to any map key.
Which way do you and others consider the most suitable ?
2) I think Section 4 will actually hinder transition rather than help
it. If a server doesn't support JSContact, there are no amount of
query parameters that a client can send to make it do so. Therefore,
we should treat this like any other extension... server's just send it
if they have it.
If there is a desire to save hamster wheel time (i.e. bandwidth),
shouldn't we try to make use of the "subsetting" extension?
[ML] The main reason supporting the proposed approach is to avoid to
duplicate contact data. Conceptually, it seems to me the best way to go
because jCard and JSContact are alternative formats for the same
information.
The other reason is that servers can realize when the transition is
really concluded because no more clients use the jcard parameter so that
there is no risk to break the response.
Otherwise, the servers couldn't know when it's time to remove jCard from
the responses and that decision would be made arbitrarily.
Furthermore, I see many drawbacks in returning both jCard and JSContact
in the same response such as the implications on the use of the fn
parameter in both standard and reverse searches (see point 3), and
duplicating some possible items of the redacted array.
I would leave the document as is about this point unless there was a
large consensus on treating JSContact as additional to jCard.
And if there is a desire to indicate a server has deprecated JCard
(YES!!!), perhaps a "jcard_deprecated" RDAP conformance value can be
used for that.
[ML] Sounds reasonable to me to include such an RDAP conformance tag in
the help response.
3) There is no support for section 3.2.3 of RFC 9082, specifically the
name search. The current pattern is "entities?fn=XXX". The use of "fn"
parameter is a bit unfortunate, but this draft should indicate how a
server supporting only JSContact maps this query.
[ML] On the assumption that either jCard or JSContact is returned, think
it's embedded in the mapping between the vCard fn and JSContact fullName
as described in the appendix.
The query parameter remains fn but it is mapped to another RDAP property.
Best,
Mario
Thanks.
-andy
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. 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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
