On Mon, Apr 16, 2018, at 16:03, Gould, James wrote: > Thanks for your thoughts of the 4 options presented for handling the > returning of a poll message that the client does not support based on > the client login services. To note, this is not specific to draft-ietf- > regext-change-poll, so it is an important topic for defining a generic > solution for all poll messages.
I agree, hence: 1) I change the subject 2) I am also wondering if we are not overdesigning something: obviously this problem exists since the beginning of EPP and can only have grown much worse with the additions of new registries, new registrars and new EPP extensions... but as far as I know this subject has never been discussed and no registrar came complaining about the issue So, for this reason I am still inclined more toward "do nothing" and let the registrars get all messages and deal with them. > I re-reviewing the options, I believe > option 4 is the only option that is protocol compliant We will remain in disagreement. > For option 4, I propose to > define a simple <msgQ><msg> ABNF formatted message that indicates what > poll message service namespaces (object or extension) are not supported > are therefore not returned by the server. I still stand the position that <msg> is defined for human consumption and hence any "formatting" in it is at least violating the spirit of the protocol. So I do not support that. > A poll message may include > multiple EPP services (object and extensions). It would be up to the > server to filter the services not supported by the client and add the > service namespace to the encoded <msgQ><msg> element. So you are proposing that: 1) all registries change their software (filtering messages) and 2) all registrars change their software, to parse the special format in <msg> I fear that this a lot of changes, and I am not really sure you can count on them. And starting with "registrar X did not implement parsing of messages in namespace Y" you arrive to a solution that is "registrar X must parse specific content inside <msg>". If the registrar was not convinced to do the first point, I am not sure it will get convinced to do the second one anyway. Hence I still think the status quo is better and let the registries send all messages. > JG-I don’t believe the server returning something that the client does > support based on the login services as being protocol compliant. There > is the issue of the message becoming a poison message for validating > clients. The Verisign EPP SDK does support XML schema validation of the > responses by default, where the server returning an XML namespace that > is not configured on the client-side will result in an XML parser error > and result in a poison poll message. This is only one implementation possible. Like I said previously, since these messages are by definition not realtime I see no harms (and only benefits) for the registrar to get all messages, store them, and parse them later. In that way there is no poison message, and full dynamic support of all namespaces. > The XML schema validation can be > disabled, but it really should not need to be disabled if the server is > protocol compliant. Validating poll messages do not need to be done in real time inside the transaction. It can be done asynchronously outside of it. > JG-I agree that creating a new extension for this runs into the same > issue of the client not supporting the new purpose built extension. I > don’t view this as a realistic option. You are creating a "mini" extension by embedding some format inside the <msg> element. > JG-I agree that this is not perfect, but it is the only option that is > protocol compliant, that will not result in a poison poll message, and > will enable the server to convey to the client the XML namespaces of the > services (object and extensions) that they can request the attributes > out-of-band using the message id. I still think that sending all messages and letting the registrars validate them out of the EPP session is the simpler solution. Also, like I said, noone complained on all of this since EPP started, so maybe affected registrars and registries should speak up... -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
