Hi all This is a programmatic approach to let the client know that there is some information in an EPP extension that the server would like to communicate to the client. The intent is, that the client would include the missing extension in the login services at login in case automatic processing is desired (parsing, validating). Otherwise the <extValue> part can still simply be ignored without any downside for the client.
In any case the information is there, so it can also be processed at a later point in time if the message has been persisted. This is a benefit because once a poll message was polled and acknowledged, there is no way for the client to request the same poll message again. We are planing to implement poll messages with the draft-ietf-regext-change-poll extension for the following registry initiated use cases where the registrar is not directly involved in: 1. Changes on DS records through our automated DNSSec provisioning process according to RFC 7344 and RFC 8078 2. Deactivation and ultimately Deletion of domain names that play a role in distributing malware or for other (legal) reasons 3. Other Transform commands like changing of authinfo or name server by the registry In some cases sending the poll message without the relevant extensions would not make much sense since the registrar would have to guess why the poll message was sent and what actually changed. If you can agree to this reasoning please provide some feedback but any contribution to the discussion is welcome :) Thanks, Martin Casanova --- SWITCH Martin Casanova, Domain Applications Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 55, direct +41 44 268 16 25 martin.casan...@switch.ch, www.switch.ch Working for a better digital world On 01.10.2018 16:34, Gould, James wrote: > Hi, > > Based on an action item from IETF-102, Martin Casanova and I created the BCP > draft-gould-casanova-regext-unhandled-namespaces to describe an approach for > EPP unhandled namespaces. Please review and provide feedback. We would like > to have an agenda item (10 minutes) at the IETF-103 REGEXT WG meeting to > introduce and discuss the draft. > > Thanks, > > — > > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 10/1/18, 10:20 AM, "internet-dra...@ietf.org" <internet-dra...@ietf.org> > wrote: > > > A new version of I-D, > draft-gould-casanova-regext-unhandled-namespaces-00.txt > has been successfully submitted by James Gould and posted to the > IETF repository. > > Name: draft-gould-casanova-regext-unhandled-namespaces > Revision: 00 > Title: Extensible Provisioning Protocol (EPP) Unhandled > Namespaces > Document date: 2018-10-01 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-gould-casanova-regext-unhandled-namespaces-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/ > Htmlized: > https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gould-casanova-regext-unhandled-namespaces > > > Abstract: > The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, > includes a method for the client and server to determine the objects > to be managed during a session and the object extensions to be used > during a session. The services are identified using namespace URIs. > How should the server handle service data that needs to be returned > in the response when the client does not support the required service > namespace URI, which is referred to as an unhandled namespace? An > unhandled namespace is a significant issue for the processing of RFC > 5730 poll messages, since poll messages are inserted by the server > prior to knowing the supported client services, and the client needs > to be capable of processing all poll messages. This document defines > an operational practice that enables the server to return information > associated with unhandled namespace URIs that is compliant with the > negotiated services defined in RFC 5730. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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
