Hi Andy,
please find my comments below.
Il 09/06/2023 17:41, Andrew Newton ha scritto:
On Fri, Jun 9, 2023 at 10:03 AM Jasdip Singh <jasd...@arin.net> wrote:
Hello Mario,
Your answer made my day! :) I'm still LOL about your "it wouldn't be short-sighted
but completely blind" point. Yah, good to think this through before we as a WG take
the next step. I recall one of the laws of simplicity [1]: law 9 which says that some
things can never be made simple. May be, JSContact falls into that category. Trusting
that the CalExt WG thought through about not unnecessarily introducing implementation
complexity for JSContact.
Regards,
Jasdip
[1] http://lawsofsimplicity.com/
TBH, it was the JSContact patchobject that made me re-examine this
space. I don't know the requirements for CalExt, but the necessity to
implement a JSON patching framework to parse postal addresses seems to
me to be beyond what is reasonable for RDAP.
[ML] CalExt adopted the same approach in designing JSCalendar.
Anyway, the reason supporting the use of patchObject is simple: it is a
more reusable and extensible approach than replicating in many objects
the information needed to build language-dependent alternatives.
vCard makes use of the LANGUAGE and ALTID parameters to build
language-dependent alternatives. The two parameters are jointly allowed
for about ten properties.
In designing JSContact, instead of replicating that information in each
of the ten JSContact counterparts of those vCard properties, we opted
for defining a single point in the spec containing all the
localizations. So doing, language based alternatives of a contact can
always be built in the same way. This a big vantage especially for
client applications which can provide a better user experience by
enabling the language selection.
For example, suppose you have a contact card whose default language is
Japanese but an English version is provided as well.
If you want to display the Japanese version, you just need to ignore the
localizations. If you want do display the English vertsion, take the
contact card, apply the patches (no matter if you are patching a
standard property or an extension), display the resulting contact card.
To be noted that extensions which can be localized don't need to include
information to build language-dependent alternatives.
On server side, you need to put the localized object and the
corresponding localization in two different places but the steps to be
done are, even in this case, always the same: construct the default
language version of an object, put it into the right place of the card,
construct the localization and put it as a generic object into the
localizations map.
On both sides, you need to know JSONPointer concepts and leverage the
capabilities of a JSONPointer library.
The implementation in jscontact-tools took to me very short time and
frankly I'm not a great Java programmer.
Hope now it's more clear why we have used PatchObject.
Finally, consider that CalExt members usually join other forums like
CalConnect where people are highly experienced with iCalendar and vCard.
With regard to RDAP, honestlty can't evaluate the average number of
contact properties that might be provided in other languages but the
example in Fig.15 of RFC 9083 includes 7 properties that could be
potentially localized: fn, n, org, title, role and two adr intances (one
structured and one unstructured). If we consider the contact information
defined by RFC 5733, the minimal set of properties that can be localized
includes: fn, org and adr.
James has also pointed
out several times that the JSContact UID may not be a good fit for
RDAP.
[ML] JSContact uid takes the same role as jCard fn. Both of them are
required. Depending on which format a server uses to represent JSContact
uid, it can be redacted by either the replacementValue or the emptyValue
method while jCard fn can be redacted only by emptyValue method.
Therefore, after the discussion we have had, don't see why it could be
an issue.
Neither it looked an issue for you, if I remember well.
On 6/9/23, 5:02 AM, "Mario Loffredo" <mario.loffr...@iit.cnr.it
<mailto:mario.loffr...@iit.cnr.it>> wrote:
Hi Jasdip,
Il 08/06/2023 15:39, Jasdip Singh ha scritto:
True, we could define an entity object class that serves the DNR and RIR
purposes with a simpler JSON, just like we chose to define domain, IP network,
and autonomous system number object classes that are specific to these
registries' business. However, before abandoning the JSContact effort, one
question to ask would be: Would it be short-sighted in precluding future user
cases for entities in other registries (say, RDAP use for space related
registration data)?
Jasdip
This is a good question to ask? What if a space registry needs to use
RDAP? Let's say they need star-dates, celestial orbital planes, and
jump-gate coordinates.
Does JSContact currently support star-dates, celestial orbital planes,
and jump-gate coordinates? It probably does not, and therefore they
would have to extend JSContact.
So if they can extend JSContact, why can't they just write an
extension for RDAP itself. In the end, that would be simpler IMHO.
[ML] If reasons supporting JSContact in RDAP exist, they are not
celestial but absolutely terrestrial.
It is also possible that we define a SimpleContact and fail to account
for something a registry is doing today.
If that happens, that registry can still use jCard. As Marc has
pointed out, jCard will be with us for some time to come.
Or they too can create an RDAP extension.
That said, I have high confidence we can create a SimpleContact that
addresses 99% of what is needed given the gTLD space is well-defined,
many of the ccTLDs are similar to gTLDs (many of them run gTLDs these
days), and the RIR space is also defined.
[ML] Think that your conclusions need no more words from my side.
Personally I see no solid reasons to replace JSContact with another
fully object-oriented representation based on your arguments. But I can
be bias.
I expect that shortly the chairs will formally ask the WG members to
manifest their support to rdap-jscontact. Whatever happens, I'll respect
the WG decision.
Anyway, if a new representation based on a JSON transliteration of
RFC5733 were preferred, IMHO it would be fair that Gavin was the
leading author.
Best,
Mario
P.S.
Lesson learned: considering that I'm almost sixty, perhaps I'm not so
bad as a Java programmer :-)
[ML] Would like to answer your question trying at the same time to recap
the reasons why 3 years ago we didn't bring on Gavin's proposal about "a
straight mapping of RFC5733 contact objects into JSON".
I remember that at ROW 2019 George Michaelson from APNIC gave a
presentation
(https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf
<https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf>)
about which requirements a contact representation aiming to replace
jCard was supposed to meet according to his experience.
In that circumstance, it was clear to everyone that the EPP contact
representation was pretty unfit to handle non-western registry data in
general.
Think that hopefully all of those requirements are matched by JSContact
(e.g. we have recently updated the spec to better model non-western
addresses but the work is still ongoing).
Tom and George, can you please say your word on this matter ?
Definitively, I believe that embracing the proposal of a contact data
format based on RFC 5733 would be a huge step backwards in facing this
problem.
The idea is not to solely base it on RFC 5733. We know that won't
work. The idea is to find a simpler solution that can be mapped into
plain structures much the same way the rest of RDAP works.
And thanks to Tom and George, we do have a good idea of the needs that
EPP doesn't provide:
https://datatracker.ietf.org/doc/html/draft-harrison-regext-rdap-jcard-profile-00
-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
