Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Patrick Mevzek <[e-mail]>]

On Wed, Jan 31, 2018, at 18:11, Gould, James wrote:
> Yes, there is no great solution to the problem of including extensions 
> (object or command-response) in poll messages to clients that don’t 
> support the extension as indicated by their login services.  So, to 
> clarifying for the list, there are 4 options that include:

I favor option 1 (return the extension independent of the login services) from your list.

And now for my detailed rationale about that:

- the list of extensions at greeting/login time do not convey enough semantics, like for example which extension is mandatory for login (especially complicated when the registry offers at the same time multiple versions of the same  extension). The registry can only react by refusing the login, hopefully with a good enough error message, but nothing is guaranteed here.
So for now, this kind of information is lost in documentation (James, another useful data item to have in the Registry Mapping in fact).

- the registrar has to specifically acknowledge a message, after having seen it; so the responsability is on him.

- poll results, aka notification messages are by definition not real time: a registrar could as well download them all, store them locally in some way and parse them later, including later when he has a software capable of understanding them

- some registries let registrars choose, out-of-band, which kind of notification messages they wish to receive; hence when this feature exists it should again be the burden of the registrar to make sure it receives the notification it needs to receive.

- giving the registrar all messages, irrespective of its choices at login time, is also the case giving less work to the server.

>   2.  Return an Error (e.g., 2307 “Unimplemented object service”) to 
> Poll Request for Unsupported Poll Message

This would be hugely detrimental for registrars because this would block all of their queue for one message about something maybe that they explicitely do not care about and have not implemented the relevant extension.

>   3.  Return a Successful EPP Poll Response with an Extension Element 
> that Indicates Lack of Client Support

If this means the original message is lost, I think it is a show stopper.
And if the registrar was not inclined to code a parser for some registry notification that forces the registry to respond with this case, why should we imagine that he would have coded the parser for this new extension also?

>   4.  Return a Successful EPP Poll Response with an Encoded <msgQ><msg> 
> Element Indicating Lack of Client Support

Same remark. Also <msg> is defined as a human-readable element content, hence
I do not think it is good to overload it with other data in it formatted
in some way. XML is a format, if you need to carry some formatted things it should be using XML elements/attributes, and not be serialized in some way in a string element.

-- 
  Patrick Mevzek
  [e-mail]