Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Patrick Mevzek <[e-mail]>]

On Mon, Jul 16, 2018, at 16:46, Martin Casanova wrote:
> The precondition of this approach is, that we actually can ask all 
> registrars to prepare their clients to at least tolerate new poll 
> messages and to update their business logic in order to process the 
> newly given information properly if they wish to do so. I think this 
> should be the case and no problem for most registrars already.

I am not so sure it would not be a problem, and if we take into account all
registries existing and hence all registrars, I am quite sure this will
not be possible in all cases.
Whatever we do, having a solution based on saying to the registrar "update your client
first" is not going to fare well.
I am even not sure many registries would really like to deploy something like
that, knowing that they will get push back from registrars.
 
> However we also considered to implement a server side flag to give 
> registrars an out of band way  to “opt out” of receiving poll messages 
> with certain extensions.  Also because we are still discussing if and 
> how triggering of normally registry initialed messages by clients could 
> be realized for integration testing of their business logic.

Indeed some registries allow registrars, through a website, to define which messages they want to receive. Not necessarily at the extension level but things like "outgoing transfer", "unlinked contact deletion", etc.

> I think it should be good practice to have a process where new poll 
> messages are allowed as per default,

The problem with that is that it could theoretically work for registrars if
1) they have access to documentation explaining all of these messages
2) they have access to it far in advance.

This does not always happen like that.
And otherwise all validating client will choke.

Imagine: a registry says, on day X we do a maintenance and after it we will create new notifications with namespace Y.
The idea is probably that just on day X all clients are updated immediately to login with namespace Y in order to receive notifications based on namespace Y.
We all know however that not all clients will upgrade at that time, but they may get such a notification. So the registry has to decide it what it does with the message using Y where the registrar did not log in with Y. Saying: "please relogin with Y before being able to poll your messages" is certainly not something registrars will be happy with.

> eventually with an optional 
> mechanism to spare certain clients from receiving messages they actually 
> don't care about, in order to drive the progress of using EPP 
> extensions.

This is indeed more pragmatic. But all this mechanism to define which messages to accept
will be outside the EPP protocol and this WG.

> I will participate this afternoon remotely. See you soon.

I will try to listen too, or be on Jabber.

-- 
  Patrick Mevzek
  [e-mail]