Subject: [regext] RDAP jCard profile

From: Tom Harrison <[email-masked]>
Date: Mon, 8 Jul 2019 04:19:12 +0000

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

---

From: Cameron Hall <[email-masked]>
Date: Mon, 8 Jul 2019 15:28:43 +1000

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 <[email-masked]> wrote:

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: George Michaelson <[email-masked]>
Date: Mon, 8 Jul 2019 16:11:59 +1000

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

On Mon, Jul 8, 2019 at 3:31 PM Cameron Hall
<[email-masked]> 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.
>
> - Cameron

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Jul 2019 11:12:33 +0000

Agreed. This sounds like a very appropriate topic for high-bandwidth discussion.

Scott

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of George Michaelson
> Sent: Monday, July 8, 2019 2:12 AM
> To: Cameron Hall <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [regext] RDAP jCard profile
>
> 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
>
> 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.
> >
> 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.
> >
> >> (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
> >>

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 10 Jul 2019 10:37:23 +0200

Hi George,

> existing implementation. Both are worth discussing.

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, 8 Jul 2019 at 14:19, Tom Harrison<[email-masked]>  wrote:
>>> Hi all,
>>>
>>> This draft

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:[email-masked]
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: George Michaelson <[email-masked]>
Date: Thu, 11 Jul 2019 13:38:47 +1000

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 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.

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.

-George

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 12 Jul 2019 10:24:38 +0200

Hi George,

> they see. This feels like a useful, and significant improvement on

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.

> 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.

> our profile and help us understand what complexities remain if this is

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Jul 2019 11:02:52 +0000

> From: regext <[email-masked]> On Behalf Of Mario Loffredo
> Sent: Friday, July 12, 2019 4:25 AM
> To: George Michaelson <[email-masked]>
> Cc: [email-masked]

[snip]

> The "contact-uri" element has an ad-hoc meaning described by the ICANN

Mario, the contact-uri element *was* originally an ICANN thing, but it's now properly structured and defined. See RFC 8605:

https://datatracker.ietf.org/doc/rfc8605/

Here's the IANA registry:

https://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 12 Jul 2019 14:57:36 +0200

Hi Scott,

> https://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml

Do you mean that "contact-uri" should be used in place of "url" to 
represent the link to a registrar home page?

It seems to me that url element as described in RFC6350 fits better in 
this case.

URL purpose: To specify a uniform resource locator associated with the
object to which the vCard refers. Examples for individuals
include personal web sites, blogs, and social networking site
identifiers.

CONTACT-URI purpose: RDAP entity information can be redacted under certain
circumstances (e.g., privacy). The Temporary Specification requires
that RDAP entity objects representing "Registrant", "Admin", and
"Tech" contacts contain an email address or a location for a web form
to facilitate email communication with the relevant contact in a way
that does not identify the associated individual. The CONTACT-URI
property can be used to include URIs representing an email address or
a location for a web form.

Best,

mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Jul 2019 13:00:58 +0000

> From: Mario Loffredo <[email-masked]>
> Sent: Friday, July 12, 2019 8:58 AM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Cc: [email-masked]
> >> The "contact-uri" element has an ad-hoc meaning described by the
> >> ICANN RDAP profile.
> > Mario, the contact-uri element *was* originally an ICANN thing, but it's
> now properly structured and defined. See RFC 8605:
> >
> Do you mean that "contact-uri" should be used in place of "url" to represent
> the link to a registrar home page?

No, not at all. I'm simply noting that the element has a formal specification now.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 12 Jul 2019 15:16:28 +0200

> No, not at all. I'm simply noting that the element has a formal specification now.

OK.

Maybe I didn't make myself clear. I didn't mean that its use is limited 
only to RDAP providers which are subject to ICANN operational profile 
but it is reserved for a specific purpose.

mario