James, Patrick Partly I understand Patrick's argument that the introduction of new types of poll messages could cause a problem for clients if their business logic is not prepared for it, even if technically the message can be received without any problem. Also our rule of restricting not enabled clients to login with DNSSec has to fall. This rule will be obsolete with the CDS process anyway (RFC-7344 and RFC-8078)
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. 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. I think it should be good practice to have a process where new poll messages are allowed as per default, 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. I will participate this afternoon remotely. See you soon. Martin Casanova ________________________________________ Von: regext [regext-boun...@ietf.org]" im Auftrag von "Gould, James [jgould=40verisign....@dmarc.ietf.org] Gesendet: Montag, 16. Juli 2018 13:06 An: Patrick Mevzek; regext@ietf.org Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt) Patrick, Yes, I believe the idea that Martin came up with to use the <extValue> element with the inclusion of the full unhandled XML block is the best option thus far. It honors the client login services, it includes all of the XML for later processing, and it does not cause XML parsing failures or marshaling failures. I implemented each of the discussed approaches using a stub server and a validating client, and this approach works best in my opinion. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/16/18, 12:20 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Thu, Jun 14, 2018, at 16:04, Gould, James wrote: > This approach looks good to me. It has the advantage of providing the > unhandled information in an element that is meant for machine processing > instead of using the <msgQ><msg> element that’s meant is meant to be > human readable. The other advantage is that the contents of the <value> > element is not processed by the XML parser (e.g., > processContents=”skip”), meaning it would not cause an XML parser error. > > This approach could include the entire unhandled extension block without > causing client-side parsing or unmarshalling issues. This "could" should be a "must", otherwise a registrar has no way to just download the message for later consumption without having the need to login will all possible extensions. Again please take into account this example that exists today: some registries restrict the extensions can be used on login, because some may be related to specific accredition, like secdns. So some registrars may not even be able to put some extensions there, but may get notifications with messages using these exceptions, as they do not control what kind of messages they get and some may appear due to actions from other parties, like other registrars or the registry itself. But like I said all of this still quite bends the RFC5730 spirit I think where value/extValue should be mostly for errors and value should reference a client provided element, which is not the case in these examples. This latest idea from Martin and you is probably the best one we discussed about as of yet, and if I could get convinced to add myself on the consensus for it, I am still uneasy by how it uses RFC5730 structures. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
