Hi George,
Il 11/07/2019 05:38, George Michaelson ha scritto:
At the ICANN RoW I said (and repeat here) the primary concern I have,
is the maintenance of BOTH i8n, and multiple value responses.
This is because I am concerned we are heading back to an anglo-ASCII
centric view, and I have to deal with significant numbers of
non-western resource holders.
I want multiple values (either as sets, or pairs within a single
object, I don't care) because I want to be able to support the ASCII
for westerners and non-locals, and the local language for local use.
We have a HTTP signalling method to indicate language preference,
which can guide how servers respond, and how clients interpret what
they see. This feels like a useful, and significant improvement on
WHOIS.
I have always believed like you that a JSON contact representation as an
alternative to jCard should take into account non-ASCII full texts to
describe some information.
This is why, the first JSContact proposal has been updated to represent
unstructured data as well as the languages associated to full names.
Obviously, the current version is still not comprehensive but, at the
same time, I think it isn't very distant from your perspective.
I have no problem with jSContact in *hypothesis*, beyond having
already made my (I am speaking in sweeping terms here: other people
did the work) investment in the RIR RDAP, which as I have said is now
complete and worldwide, and I find it strange that with a
self-assessment of "not the smartest kid on the block" we were fine
implementing JCard. Sure, it was a burden, but its a one-time burden.
Yes, so did I. But there are other issues due to the jCard structure
beyond the customization of serialization/deserialization methods.
I have implemented an RDAP validator and the JSON schema representation
of jCard has been very hard.
I have used a JSON transformation library to provide different views of
the RDAP response according to the user profile and I have found similar
problems because the trasformer meta-language couldn't be easily applied
to jCard jagged arrays.
Definitively, jCard doesn't make its processing easy.
We've proposed a profile for JCard to try and set limits on the
open-ended spec, and clarify what we need. I think a reasonable
request in that context is for people looking at JSContact to look at
our profile and help us understand what complexities remain if this is
adopted.
If the WG will decide that JSContact shall be provided by RDAP providers
only as an optional capability, both the documents will be useful.
IMHO, the RDAP jCard profile should contain also the "url" element to
represent the link to a web page in general (e.g. a registrar web page).
The "contact-uri" element has an ad-hoc meaning described by the ICANN
RDAP profile.
Best,
mario
-George
On Wed, Jul 10, 2019 at 6:38 PM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
Hi George,
Il 08/07/2019 08:11, George Michaelson ha scritto:
I think we should have time at the Montreal meeting to discuss this
f2f. You have a proposal for a simplified model requiring
re-implementation, we have a proposal for a simplification of the
existing implementation. Both are worth discussing.
-George
I agree.
It is certain that jCard is considered inefficient in many contexts
because implementers need to define their own contact data model and
customize serialization/deserialization methods provided by JSON
libraries in order to convert jCard into/from their internal
representation. The idea of having a common JSON contact representation,
more efficient than jCard, inspired the JSContact proposal.
It is also true that some RDAP implementers have raised objections to
the use of jCard, so much so that jCard fix/replacement has been debated
inside and outside this WG.
As a JSContact co-author and RDAP implementer, I have developed a new
version of .it RDAP server providing the contact information according
to such a new format as an optional capability. I did it with the main
purpose of gathering feedbacks about JSContact "as is" and, secondly,
envisage its use in the RDAP context.
Anyway, JSContact is indipendent of RDAP and the WG might decide that
there is no need to change the RDAP response or JSContact is not the
best solution for replacing jCard in RDAP.
Best,
mario
On Mon, Jul 8, 2019 at 3:31 PM Cameron Hall
<ch...@staff.synergywholesale.com> wrote:
Hi Tom,
Having recently built our own RDAP server to meet the implementation deadline,
and experienced first hand the implementation of jCard; I don't believe that
simplifying the profile is sufficient enough.
I'm under the assumption that jCard (vCard) was chosen due to its flexibility and wide adoption in
terms of email/calendar/contact clients. While I can appreciate the flexibility, it was very
tedious and complex to implement given that it is not human readable and not
"straight-forward" so to speak. I do appreciate the specification of the fields required
by RDAP in your draft, but I still think that jCard is "over-engineered" for the purpose
of reporting contacts. The format for domain contact objects/mappings haven't changed in nearly ten
years and given the direction the world is moving with privacy regulations I can't imagine us
taking full-advantage of what jCard has to offer.
I believe that JSContact better fits the RDAP system due to its overall
simplicity. Being both human and machine readable is a huge advantage in
comparison, as it will lessen implementation time and be a not require one to
wrap their head around the complexities of the vCard/jCard formats.
Not to mention, JSContact would complement the REST API quite nicely.
- Cameron
On Mon, 8 Jul 2019 at 14:19, Tom Harrison<t...@apnic.net> wrote:
Hi all,
This draft
(https://tools.ietf.org/html/draft-harrison-regext-rdap-jcard-profile-00)
is a profile of jCard for use in RDAP. It is based on the jCard
properties/parameters etc. used by the current RDAP servers, plus some
extras that will likely be in use soon (e.g. support for properties in
multiple languages). Before moving forward with something like
JSContact, we'd like to see whether profiling jCard will simplify it
sufficiently for the group that it's no longer necessary to replace it
with a new format (though obviously this can't fix problems that occur
due to the format itself, such as difficulties with
marshalling/unmarshalling jCard data). Feedback would be appreciated.
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
