Subject: Re: [regext] Preparing for IETF 100

From: Mario Loffredo <[email-masked]>
Date: Sun, 1 Oct 2017 12:38:12 +0200

Dear Antoin,

I'd like to discuss https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ and two new drafts about partial respose and reverse search in RDAP that will be available in a couple of days.

Regards
Mario

Inviato da iPhone

> Il giorno 15 set 2017, alle ore 15:29, Antoin Verschuren <[email-masked]> ha scritto:
> 
> Dear Working group,
> 
> It’s time to start planning for IETF 100 in Singapore.
> To be able to judge if we need a working session, we have 2 questions for you
> 
> 1. Please submit agenda items to the list.
> 2. Please indicate if you need working time or update time for your item.
> 
> Since we need to request meeting slots within a fortnight please submit your discussion items before friday 22th so we can discuss if:
> 
> 1. We can discuss items in a interim meeting before IETF 100 and only need 1 update session.
> 2. We need both a working session and a short update session for IETF 100.
> 3. Or we can do with one longer joint working/update session.
> 
> Thanx,
> 
> Jim and Antoin
> 
> - --
> Antoin Verschuren
> 
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
> 
> 
> 
> 
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 9 Oct 2017 17:41:21 +0200

Hi Andy,

it seems to me that some corrections should be made:

- the last three properties of "secureDNS" definition should  be moved 
inside the "domain_mixin" definition;
- the "autnum_mixin" definition should contain the "country" property;
- the "event" definition should be splitted in two like the following:

$noActorEvent = {
"eventAction" : string,
"eventDate" : datetime,
$links,
$lang
}

$event = {
$noActorEvent,
"eventActor" : string,
}

The noActorEvent type should be used in the definition of "asEventActor" 
property
because RFC7483 states that each object in the array must not have an 
"eventActor" member.

In addition, there is a case of redundancy but I don't know if it is an 
error or it is allowed by JCR overriding rules.
The presence of the "lang" property in a lookup response can be derived 
by following two paths.  For example, in a domain lookup response lang 
can be derived both by domain_response->response_mixin->lang
and domain_response->domain_mixin->common_mixin->lang

Regards,
Mario

Il 29/09/2017 18:15, Andrew Newton ha scritto:
> Antoin,
>
> Sorry for being late with this but I wasn't sure I'd get the document
> updated in time.
>
> The topic of RDAP and schemas came up in the last meeting. If
> possible, I'd like to discuss
> draft-newton-rdap-jcr.
> https://datatracker.ietf.org/doc/draft-newton-rdap-jcr/
>
> -andy
>
> On Fri, Sep 15, 2017 at 9:29 AM, Antoin Verschuren<[email-masked]>  wrote:
>> Dear Working group,
>>

-- 
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 050 3153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: "Andrew Newton" <[email-masked]>
Date: Wed, 11 Oct 2017 14:08:32 +0000

Mario,

Thanks for reviewing this. My replies are in-line.

------ Original Message ------
From: "Mario Loffredo" <[email-masked]>
To: "Andrew Newton" <[email-masked]>
Cc: "Registration Protocols Extensions" <[email-masked]>
Sent: 10/9/2017 11:41:21 AM
Subject: Re: [regext] Preparing for IETF 100

>      - the last three properties of "secureDNS" definition should  be   
>    moved inside the "domain_mixin" definition;
>
Good catch! Thanks.

>      - the "autnum_mixin" definition should contain the "country"      
Another good catch. Thanks.

>      The noActorEvent type should be used in the definition of      
>"asEventActor" property
>      because RFC7483 states that each object in the array must not have 
>      an "eventActor" member.
>
>

Yes, I agree. I'll also add some comments to explain it. Thanks.

>      In addition, there is a case of redundancy but I don't know if it  
>     is an error or it is allowed by JCR overriding rules.
>      The presence of the "lang" property in a lookup response can be    
>   derived by following two paths.  For example, in a domain lookup      
>response lang can be derived both by      
>domain_response->response_mixin->lang

Since lang is optional, there is no harm. However, I see no reason why 
it should be in both places. Thanks for point this out.

I'll make these corrections on the next version of the draft.

-andy

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 11 Oct 2017 17:20:50 +0200

Hi Andy,

I list three other possible errors. I don't know if they are real 
errors, most probably I misunderstood some statements of the protocol:

- in RFC7480 (section "5.3")  it is written "If a server wishes to 
respond that it has an empty result set (that is, no data appropriately 
satisfying the query), it returns a 404  (Not Found) response code."
    According to this statement, it seems that search response arrays 
should have at least one element so for example the rule 
$domainSearchResult = "domainSearchResult" : [ $domain_oc * ] should be 
replaced by the rule $domainSearchResult = "domainSearchResult" : [ 
$domain_oc + ]

- Is it possible to have RDAP responses without any value (at least 
"rdap_level_*" seems to be required) in the rdapConformance array? If 
no, the rule about rdapConformance should be $rdapConformance = 
"rdapConformance" : [ string + ]

- Handle seems to be required for an entity. If so, the handle defintion 
in common_mixin should be overrided by an identical definition without  
'?' in entity_mixin. The same occurs if rdapConformance is required for 
all the reponses except the error response.

Regards,
Mario

Il 11/10/2017 16:08, Andrew Newton ha scritto:
>>      - the last three properties of "secureDNS" definition should  
>> be      moved inside the "domain_mixin" definition;
>>
> Good catch! Thanks.
>
>>      because RFC7483 states that each object in the array must not 
>> have      an "eventActor" member.
>>
>>
>
>>      In addition, there is a case of redundancy but I don't know if 
>> it      is an error or it is allowed by JCR overriding rules.
>>      The presence of the "lang" property in a lookup response can 
>> be      derived by following two paths.  For example, in a domain 
>> lookup      response lang can be derived both by 

-- 
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 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Oct 2017 13:18:34 -0400

Mario,

Sorry for the later than usual response. My comments are inline.

On Wed, Oct 11, 2017 at 11:20 AM, Mario Loffredo
<[email-masked]> wrote:
>
> - in RFC7480 (section "5.3")  it is written "If a server wishes to respond
> that it has an empty result set (that is, no data appropriately satisfying
> the query), it returns a 404  (Not Found) response code."
>    According to this statement, it seems that search response arrays should
> have at least one element so for example the rule $domainSearchResult =
> "domainSearchResult" : [ $domain_oc * ] should be replaced by the rule
> $domainSearchResult = "domainSearchResult" : [ $domain_oc + ]
>
> "rdap_level_*" seems to be required) in the rdapConformance array? If no,
> the rule about rdapConformance should be $rdapConformance =

These are good points, but I'm not sure I can answer them (they are
working group interpretations). But these issues do highlight why a
more formal syntax is a good thing.

>
> - Handle seems to be required for an entity. If so, the handle defintion in
> common_mixin should be overrided by an identical definition without  '?' in
> entity_mixin. The same occurs if rdapConformance is required for all the
> reponses except the error response.

I think you are correct here.

-andy

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 25 Oct 2017 09:22:51 +0200

> Sorry for the later than usual response. My comments are inline.
No problem, Andy.
I ask you for another clarification. I hope the last one.
Does the proposed set of rules validate an RDAP response permissively?
I mean, do those rules validate successfully a response with extra fields?

If yes, it seems to me that the help_response rule validates almost 
everything (except the basic error response).
I don't know if it is an error in JCR, it would be if root rules are 
mutually exclusive.

Regards
Mario

---

From: Andrew Newton <[email-masked]>
Date: Thu, 26 Oct 2017 14:32:28 -0400

> I mean, do those rules validate successfully a response with extra fields?

Yes. That's how RDAP is specified. JCR allows this by default, but can
be written to be strict.

> everything (except the basic error response).

Since a /help is a subset of everything else, it could be read that
way. The rules in the draft are written as permissive but it is
possible to write them more strictly.

That being said, I don't think that is the right approach for RDAP.
The thought has always been to ignore what you didn't expect. There
are already extensions which add RDAP specified structures to other
RDAP responses (see my subnets draft). Restricting things makes RDAP
extensions much more difficult.

> I don't know if it is an error in JCR, it would be if root rules are

At present, they are not.

-andy