Hi Andy,
thanks for this document. I can finally compare it with JSContact and
provide some feedback:
1) First, I'm happy to note that, with reference to the first draft
proposal included in
https://mailarchive.ietf.org/arch/msg/regext/56Nk70dpoxFOdlK2rw_QSiPlg9Q/,
some arrays of values have been turned into either objects or arrays of
objects and further information has been modeled. This is because
SimpleContact has become "more complex" to support additional features
not considered initially. In some cases, this specification is even
"more complex" than JSContact (e.g. in JSContact the name information is
represented through a single object instead of a collection). If I may,
by using your words, I would say that SimpleContact is making the same
mistake as JSContact about the use of arrays and objects.
2) It seems to me that this specification doesn't ensure the full
backward compatibility with all of the jCard features currently used in
RDAP. Here in the following some of them:
a) some registries use the LANG property to set the default language
b) some registries use the PREF parameter of TEL and EMAIL properties
(e.g., if I remeber well, APNIC represents the preference information in
email addresses)
c) some registries use the TEL-TYPE parameter (e.g. to represent work
phone numbers)
d) some further jCard features included in RFC 9083 examples don't find
counterparts in this specification (e.g. KEY, TZ, TITLE properties).
Do you plan to match such features ?
3) The EPP postal address scheme is unfit to represent some items used
in non western postal address schemes (such as district, sub-district.
block). This specification requires a server to include in
"deliveryLines" the addtional information but such additional items
cannot be clearly identified. With regard to this aspect, this
specification doesn't address the problem of representing postal
addresses other than western ones. The style is different but the
information is exactly the same as jCard.
4) About the localizations, it seems to me that this specification
assumes that one contact can include at most one kind of information and
one related localization at most, I mean one internationalized postal
address and a localized version, one ASCII email address and its UTF-8
version. Otherwise, I don't see how it would be possible to link
together multiple language-dependent alternatives. For example, how
would it be possible to link two ASCII emails with their related UTF-8
versions ?
5) I'm very curious to know the WG reaction about the use of "noJCard"
extension. AFAIK, providing an alternative represention along with
jCard in an RDAP response has not been considered an issue so far even
in case of handling large amounts of data. Most of us (not me) have
considered too complex for both clients and servers to imlement the
negotiation of the contact representation to be returned in the
response. In addition, in this case, the negotiation is made through
two extension identifiers while in rdap-jscontact setting the jscard
parameter to 1/true means that jCard is not returned.
Best,
Mario
Il 05/07/2023 14:27, Andrew Newton ha scritto:
Tom and I put together an I-D outlining what a SimpleContact might look like.
Of course I am biased, but I think this does simplify RDAP contact
data considerably.
Also note that while this I-D does support structured names (as is
found in jCard and JSContact),
we are unsure if they are needed in the RDAP context as we can find no
evidence of
structured name usage in the current RDAP ecosystem.
-andy
---------- Forwarded message ---------
From:<internet-dra...@ietf.org>
Date: Wed, Jul 5, 2023 at 8:21 AM
Subject: New Version Notification for
draft-newton-regext-rdap-simple-contact-00.txt
To: Andy Newton<a...@hxr.us>, Tom Harrison<t...@apnic.net>
A new version of I-D, draft-newton-regext-rdap-simple-contact-00.txt
has been successfully submitted by Andy Newton and posted to the
IETF repository.
Name: draft-newton-regext-rdap-simple-contact
Revision: 00
Title: RDAP Simple Contact
Document date: 2023-07-05
Group: Individual Submission
Pages: 11
URL:
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-00.txt
Status:
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/
Html:
https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-contact
Abstract:
This document describes an extension to the Registry Data Access
Protocol for entity contact data using basic JSON values, objects,
and arrays. The data model defined by this document is purposefully
limited to the data in-use by Internet Number Registries and Domain
Name Registries and does not attempt to model the full data-set that
can be expressed with other contact models such as jCard or
JSContact.
The IETF Secretariat
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Senior Technologist
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
