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 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which 
> messages to accept
> will be outside the EPP protocol and this WG.

But please also remember that if we want to tackle this problem in a generic way (and also taking care of different servers and clients strategies regarding handling of namespaces and inline/offline parsing and use) it is not limited to a single extension (the thread started long ago with changePoll) nor in fact limited to poll messages.

Imagine registrar A wanting to request a transfer from registrar B. In some registries it means that regitrar A can do a domain:info on the domain, with the authInfo to get access to all details, and specifically the contacts.
But a domain can have a secDNS part in the domain:info reply.
What happens if the registrar A did not login with the secDNS extension (maybe this case does not exist in gTLDs where DNSSEC is mandatory but again we have other registries cases to take into account)?

Should the domain:info return an error? Return everything as is? Return everything but the secDNS part?

The last case is the worst to me: some registrars may like not to support DNSSEC at all (and hence will not log in at all, or you have other cases where registries mandate specific tests to be "DNSSEC" accredited so it may not even be possible to log in with secDNS extension even if the registrar would like to) but, and especially for this, being able to detect beforehand if some client is trying to transfer to them a domain using DNSSEC, that they would like to refuse transferring.


Of course the above is only one example with a domain:info and the secDNS extension but I am sure we can find others.

This illustrates I think the distinction I made in earlier messages and the different semantic I attach to extensions listed as login: for me they are those that the client announce it will use. Of course, it has no control over messages or objects he is not the origin or the sponsor, all cases where other namespaces may appear.


-- 
  Patrick Mevzek