Hi Alessandro,
Il 21/02/2022 09:54, Alessandro Vesely ha scritto:
Hi Mario,
On Mon 21/Feb/2022 08:30:53 +0100 Mario Loffredo wrote:
Il 20/02/2022 13:17, Alessandro Vesely ha scritto:
On Wed 16/Feb/2022 15:54:01 +0100 Mario Loffredo wrote:
For what is worth, I would proceed as in the following:
1) If a contact with the abuse role exists:
1.a) If at least one pref parameter exists, I would return only
the most preferred email address;
1.b) If the pref parameter is missing, I would return all the
email addresses in order of appearance.
2) If a contact with the abuse role is missing, I would return no
abuse email address
Hope It could be helpful.
Yup, that's an applicable hint. I'd suggest to publish it as a
default profile in the next RFC. (I don't know how to get profiles,
let alone parsing them. Having a default profile allows to make
sense of APNIC's preferences.)
Don't think this is a matter of an RFC.
Why not?
Because, since the pref parameter can be added to many VCARD properties
that can be included in the RDAP response, what is stated in
https://datatracker.ietf.org/doc/html/rfc6350#section-5.3 seems enough
to me.
Special meaning of the pref parameter with regard to the specification
of the abuse mailbox should be decided by each registry autonomously.
That said, it seems to me that the APNIC's response is not ambiguous as
it appears clear (at least to me) which is the preferred abuse mailbox.
What I suggested, it can be valid as a general rule applicable to
every RDAP response provided that the server returns a contact with
the abuse role.
So the missing paragraph about "pref" could be filed as an erratum to
RFC7483?
What should such a missing paragraph say beyond what is stated in
section 5.3 of RFC6350 ?
For example, it can be applied to APNIC's abuse contacts as well as
to the abuse contacts returned by the gTLDs' RDAP servers according
to what is stated in Section 2.4.5 of
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf
Apart from that document not mentioning preferences, IMHO it is
important that "pref" has a standard meaning. If users need to gather
it from specific profiles, the very concept of a "grand unified
specification"[*] would get cracked.
The "pref" parameter already has a standard meaning defined in RFC 6350.
What I suggested is only an implementation of that general rule in this
specific case. Nothing else.
Best,
Mario
Best
Ale
--
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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
