Subject: [regext] rdap mobile app avail

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 26 Aug 2019 11:58:13 -0400

Hello,
  sorry for the cross-posting and announcement.

Just to tell that the RDAPBrowser app is now available on both ios and 
android respective app stores.

(For tech-savvy people, the app UX does not show all possible fields 
received in the JSON, but most of them, on purpose. The received JSONs 
are also available in the « RDAP Protocol » panel)

If you have any question, bug report or else, please send email to 
[email-masked]

Regards, Marc.

---

From: Marc Groeneweg <[email-masked]>
Date: Thu, 29 Aug 2019 08:11:48 +0000

All,

Due to the release of the mobile app of Marc, Blanchet we saw we differ in interpretation of some fields we have in our RDAP implementation (for .politie and .amsterdam). 
Feedback from my development on the issues given Marc is that they have chosen for a direction, that is at least now not compliant with what the mobile app aspects.

They are frustrated about this, since they have had an extensive period behind them with working on the specifications and building a sound RDAP implementation, that also is meant for .nl later this year. Intensive contact with ICANN resulted only in 'Sorry we don't know' and 'We don't have sufficient resources to give an answer now.'.

So, we have our implementation live! But how can we make sure (if not ICANN but at least the community) what compliancy means... (e.g. we return a null when we don't have a value and "" when we have an empty string value. The mobile app wants "" in all empty situations... Just an interpretation?).

I do not have the answers yet. Some of the points Marc gave us (in private mail exchange, for which I am grateful) will be solved. But that's not the point really.

Hope to hear from you all :-).

Best regards,
Marc Groeneweg

---

From: Andrew Newton <[email-masked]>
Date: Thu, 29 Aug 2019 07:42:40 -0400

Hi Marc,

First, sorry that you are feeling frustrated.

With regards to null vs empty string, in my opinion both are
incorrect. If your registry does not have the value or is not allowed
to publish the value, the correct thing to do is to simply leave the
value out of the response. There are a few required fields in RDAP,
but for the most part everything is optional.

I hope that helps.

-andy

On Thu, Aug 29, 2019 at 4:11 AM Marc Groeneweg
<Marc.Groeneweg=[email-masked]> wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 29 Aug 2019 15:07:53 +0200

Hi Andy,

Il 29/08/2019 13:42, Andrew Newton ha scritto:
> value out of the response.

In theory I agree with you but, since fn is required in jCard, how could 
it be possible to represent a fn whose value is redacted?

In addition, I wonder if it could be useful for a user to know if a 
value is unavailable or it is redacted.

mario

> There are a few required fields in RDAP,

-- 
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: "Marc Blanchet" <[email-masked]>
Date: Thu, 29 Aug 2019 09:31:01 -0400

On 29 Aug 2019, at 4:11, Marc Groeneweg wrote:

> All,
>
> Due to the release of the mobile app of Marc, Blanchet we saw we 
> differ in interpretation of some fields we have in our RDAP 
> implementation (for .politie and .amsterdam).
> Feedback from my development on the issues given Marc is that they 
> have chosen for a direction, that is at least now not compliant with 
> what the mobile app aspects.

well the important point here is not what the server or a client expects 
as of today. But what is the right thing to do and then fix whatever 
side.

To me, this is « normal »: we have collectively spent years in 
developing the RDAP specs. And now an important market for it (domains) 
is deploying like crazy with a deadline of last monday. As any standard, 
there are holes, incomplete details, ambiguity, errors, … Right now, 
AFAIK, the specs are pretty good, just some ambiguity could be relieved 
by some additional text. Last IETF, we had that conversation about 
making new version of the spec based on the deployment experience. This 
is about it.

let’s find the right answer and fix whatever implementation.

Marc.

PS. will followup on a separate email for the null vs "" issue.
>
> They are frustrated about this, since they have had an extensive 
> period behind them with working on the specifications and building a 
> sound RDAP implementation, that also is meant for .nl later this year. 
> Intensive contact with ICANN resulted only in 'Sorry we don't know' 
> and 'We don't have sufficient resources to give an answer now.'.
>
> So, we have our implementation live! But how can we make sure (if not 
> ICANN but at least the community) what compliancy means... (e.g. we 
> return a null when we don't have a value and "" when we have an empty 
> string value. The mobile app wants "" in all empty situations... Just 
> an interpretation?).

>
> I do not have the answers yet. Some of the points Marc gave us (in 
> private mail exchange, for which I am grateful) will be solved. But 
> that's not the point really.
>