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

From: Patrick Mevzek <[email-masked]>
Date: Thu, 05 Apr 2018 09:12:41 +0200

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
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 16 Apr 2018 14:03:14 +0000

Patrick,

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 re-reviewing the options, I believe option 4 is the only option that is protocol compliant and that would not result in a poison poll message.  I provide a response to your feedback embedded below prefixed with "JG-".  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.  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.  The <msgQ><msg> element is defined as mixed with a sequence of any elements that skip processing, which means that we can mix XML with text without causing negative side effects on the client-side.  Any attributes for a non-supported service (object or extension) can be retrieved from the server out-of-band using the message identifier (<msgQ> "id" attribute).    I propose supporting a list of <notSupported> XML elements appended to the end of the <msgQ><msg> text.  Each <notSupported> element contains the XML namespace of the EPP service (object or extension) that is not supported by the client.  The ABNF for the <msgQ><msg> element is:

msg                   = msg-text *LWSP *(not-supported-service *LWSP)

msg-text              = *VCHAR

not-supported-service = “<notSupported>” 1*VCHAR “</notSupported>”

The following is an example of a Change Poll Message where the client does not support the Change Poll Extension:

<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">

  <response>

    <result code="1301">

      <msg lang="en-US">

       Command completed successfully; ack to dequeue</msg>

    </result>

    <msgQ id="202" count="1">

      <qDate>2013-10-22T14:25:57.0Z</qDate>

      <msg>Registry initiated update of domain.

        <notSupported>urn:ietf:params:xml:ns:changePoll-1.0

        </notSupported>

      </msg>

    </msgQ>

    <resData>

      <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

        <domain:name>domain.example</domain:name>

        <domain:roid>EXAMPLE1-REP</domain:roid>

        <domain:status s="serverUpdateProhibited"/>

        <domain:status s="serverDeleteProhibited"/>

        <domain:status s="serverTransferProhibited"/>

        <domain:registrant>jd1234</domain:registrant>

        <domain:contact type="admin">sh8013</domain:contact>

        <domain:contact type="tech">sh8013</domain:contact>

        <domain:clID>ClientX</domain:clID>

        <domain:crID>ClientY</domain:crID>

        <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>

        <domain:upID>ClientZ</domain:upID>

        <domain:upDate>2013-10-22T14:25:57.0Z</domain:upDate>

        <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>

      </domain:infData>

    </resData>

    <trID>

      <clTRID>ABC-12345</clTRID>

      <svTRID>54321-XYZ</svTRID>

    </trID>

  </response>

</epp>

The following is an example of a Change Poll Message where the client does not support the Domain Mapping and the Change Poll Extension to show the many case:

<?xml version="1.0" encoding="UTF-8"?>

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">

  <response>

    <result code="1301">

      <msg lang="en-US">

     Command completed successfully; ack to dequeue</msg>

    </result>

    <msgQ id="202" count="1">

      <qDate>2013-10-22T14:25:57.0Z</qDate>

      <msg>Registry initiated update of domain.

         <notSupported>urn:ietf:params:xml:ns:domain-1.0

         </notSupported>

         <notSupported>urn:ietf:params:xml:ns:changePoll-1.0

         </notSupported>

       </msg>

    </msgQ>

    <trID>

      <clTRID>ABC-12345</clTRID>

      <svTRID>54321-XYZ</svTRID>

    </trID>

  </response>

</epp>

What do you think of this proposal?

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 4/5/18, 3:12 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

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.  The XML schema validation can be disabled, but it really should not need to be disabled if the server is protocol compliant.  The Verisign EPP SDK is one example of a validating client that would have an issue with the server returning a poll message independent of the login service.  I don’t view this as a realistic option.

JG-I agree that this will result in blocking the queue, which I refer to as a poison poll message.  I don’t view this as a realistic option.

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.

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.

    --

      Patrick Mevzek

      [email-masked]

    _______________________________________________

    regext mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 18 Apr 2018 08:19:26 +0200

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
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Apr 2018 13:43:14 +0000

Patrick,

This particular thread was started Martin Casanova, who brings up an excellent point that needs to be considered.  Martin, you may want to weigh on this.

I have the following questions and related thoughts:

  1.  Do you believe that it is protocol compliant for the server to return something that the client did not explicitly include in the login services?
     *   I believe that the server should not return something that the client does not include in the login services.
  2.  What is the purpose of the server’s greeting services and the client’s login services?
     *   I believe that the server and client services are used to negotiate the common set of supporting services.  The client should not pass services that the server does not support and vice-versa.
  3.  What do you do with validating clients?
     *   The Verisign EPP SDK is one implementation of a validating client, but there can be others.  A validating client would either need to be updated to support the extension or turn off validation and be capable of processing a message that it doesn’t support.  If the protocol is followed, there should be no issue with validating the XML per the supported XML schemas in either the server or the client based on #2.

You are correct that there are a set of existing EPP extensions that do include poll messages (e.g., RGP Poll Mapping, Low Balance Mapping, Launch Phase Extension, and object mappings that support transfer poll messages like Email Forwarding and Defensive Registration).  This is based on the extensions registered in the EPP Extension Registry (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).  With the exception of the RGP Poll Mapping and the Low Balance Mapping, the poll messages are associated with actions that the client previously took, so it’s reasonable to assume that the client supports it.  The Change Poll messages and the Maintenance Notice poll messages (draft-sattler-epp-registry-maintenance) are not associated with client actions, where there can be no assumption of support.  Based on past experience there have been no issues raised that I’m aware in returning messages independent of what the client includes in the login services, but I don’t believe we can blindly ignore the issue.

Since it looks like Patrick and I are most likely at an impasse, I ask the list to weigh in on the two options that include:

  1.  Server does not consider the login services when returning poll messages.  Clients may be required to consume poll messages that they don’t support.
  2.  Server considers the login services and filters non-supported extensions (object and command / response) from the poll message response with an encoded <msgQ><msg> indicating the extension namepaces not supported.  I include the proposed ABNF for the <msgQ><msg> element below along with a sample of the client’s lack of support of the Change Poll extension.

 ABNF for the <msgQ><msg> element:

msg                   = msg-text *LWSP *(not-supported-service *LWSP)
msg-text              = *VCHAR
not-supported-service = “<notSupported>” service-namespace “</notSupported>”
service-namespace     = 1*VCHAR

Sample poll message of registry initiated domain update, where the client does not support the Change Poll extension with the XML namespace “urn:ietf:params:xml:ns:changePoll-1.0”:

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/18/18, 2:19 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    I agree, hence:

    1) I change the subject

    and

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 20 Apr 2018 07:58:42 +0200

On Wed, Apr 18, 2018, at 15:43, Gould, James wrote:
> This particular thread was started Martin Casanova, who brings up an 
> excellent point that needs to be considered.  Martin, you may want to 
> weigh on this.

You can probably admit that, based on the amount of time the problem exists (basically since registries started to use EPP), and the number since then on mailing-lists about this problem, that it is not an hot topic.
That does not mean it can not be addressed, but it may mean that registries/registrars already found out solutions to this.

>   1.  Do you believe that it is protocol compliant for the server to 
> return something that the client did not explicitly include in the login 
> services?

It is certainly not ideal, but not a big problem either (in this specific case for the specific reasons I gave and will give below), and certainly to my eyes less a problem than putting format into a <msg> element that is defined for human consumption (even more so when you mix both text and XML elements in the same <msg> element, which is a peril waiting to happen)

>      *   I believe that the server and client services are used to 
> negotiate the common set of supporting services.  The client should not 
> pass services that the server does not support and vice-versa.

It is not a full negotiation since there is only one exchange and only a binary result possible (accepting the login or not).

Text says:
"A <svcs> element that contains one or more <objURI> elements that
      contain namespace URIs representing the objects to be managed
      during the session."

Note that it says objects, not messages or commands.
For me it is more tailored to let the client advertise which objects he wants to manipulate at the registry, that is which namespaces will appear in its commands.
Imagine a registry handling both domain names and let's say AS number or IP blocks, within the same EPP server.
Upon login, some clients may have rights to only manage domains or only manage AS numbers. So they advertise what they would like to do, based on server greeting. And then the server can act on that.

For me the <svcs> definition in RFC5730 does not restrict the notifications messages namespaces. So I think from this disagreement, we go then on separate ways.

>      *   The Verisign EPP SDK is one implementation of a validating 
> client, but there can be others.  A validating client would either need 
> to be updated to support the extension or turn off validation and be 
> capable of processing a message that it doesn’t support.  If the 
> protocol is followed, there should be no issue with validating the XML 
> per the supported XML schemas in either the server or the client based 
> on #2.

Again, the validating client can recognize it can not validate the notification message (if it does it synchronously which you suppose and for which I already said that there are ways to do it differently), and just dump it aside for further/later processing and before being updated if you insist on in-session immediate validation.

I think you are missing some use cases. Let me share things I have seen in various places.

First, from my experience, many registries (I can not give precise numbers I would say in the ballpark of 1 among 2) define their own namespace extension for notification messages, with more or less format.
I doubt that a validating client such as Verisign EPP SDK would work great in this case if it wants to be used for many ccTLDs especially and validate all notifications messages. It just does not fit what is happening.
Note that you do not have this problem in gTLDs where far less extensions are used.

Of course it would be so much simpler if they were not so many extensions doing the same things, but the situation is like it is for now and I doubt this will change soon, or anytime in fact.

Another important point: I know multiple EPP clients (mine included for part of the following, but I know others too) that exhibit, on purpose, one or more of the following traits:

1) not validating incoming EPP messages and even more often not validating outgoing ones.
Why? Because when you try to support many registries you tend to observe that not all registries are strictly conforming to their own EPP schemas; so it happens that you get as client some EPP messages that do not validate at all, even if given  by the registry. Of course you will say that this is the server fault and that it should be fixed (or the schema amended) and it is of course the true technical explanation but then when you have to conduct your business you can not wait on the registry to be fixed, your client should not be halted by some bogus format, it should find workarounds.

Note that it also happened for core schema. I know one registry particularly that re-used the <domain:reason> element in a <domain:check> command for more that it was designed to (which also illustrates the peril of shoehorning a formatted structure inside a free text element), and just forgetting that its schema forces it to be less 32 characters or less... and some messages did have a reason larger than that. Some registrars were not happy about that when they started to receive such messages...

So how a validating client is supposed to handle that? Just refuse the message and make it impossible to do any domain:check?
Again, certainly possible technically, but not realistic business-wise.

One could also paste here the Postel law, or its half: be liberal in what you accept
(which breaks horribly when applied in security contexts but that is another story).

2) not processing notifications at all in-session, just acking all messages immediately, after having stored them locally in a DB or something which will get consumed by some asynchronous processes.
To me this looks very efficient and solve multiple problems at once. Including the validation problem or even for message 100% validated the problem of parsing them.
Take for example the transfer case and registries sending notifications about transfers being started, refused, accepted, etc.
Not all of them, again specifically in ccTLDs, are using the standard panData element. Many of them are putting all the information (domain name, status of transfer, other registrar ID, etc...) as free text in the <msg> part of the notification. You have to parse that. You can not build a client that will have this knowledge even before connecting to the EPP server for the simple reason that often there is not even a comprehensive documentation from the registry with all the messages. So you will have to pick them up during your life. You either try to parse them immediately, or you store them for later. If you want to validate and parse them immediately what will you do for all unknown cases? Just throwing a fatal exception will again not help the registrar to do its business.

So I applaud the Verisign SDK to be strict and to stick to the technical rules and do validation always, I just do not think it could be used as is to connect to many ccTLDs registries because you will then be hit by many new namespaces, specific to one registry, that are not necessarily fully documented nor always respected by the registry itself.

To put things in perspective, extracted from my client, here are some namespaces related to registry notification messages a client can receive:

http://www.afnic.fr/xml/epp/frnic-1.4
http://rxsd.domain-registry.nl/sidn-ext-epp-1.0
http://tld-box.at/xmlns/resdata-1.1
http://www.nic.at/xsd/at-ext-message-1.0
http://www.nominet.org.uk/epp/xml/std-notifications-1.2
urn:afilias:params:xml:ns:oxrs-1.1
urn:ietf:params:xml:ns:changePoll-1.0
urn:ietf:params:xml:ns:cira-1.0
urn:ietf:params:xml:ns:extreport-1.0
urn:ietf:params:xml:ns:poll-1.0

and this is certainly not exhaustive...

How many open or closed EPP clients do you know that are capable of both parsing all these extensions and validating them (putting aside the problem of receiving an EPP frame not even respecting the schema associated to the namespace)? I bet you can count them on one hand...

> You are correct that there are a set of existing EPP extensions that do 
> include poll messages (e.g., RGP Poll Mapping, Low Balance Mapping, 
> Launch Phase Extension, and object mappings that support transfer poll 
> messages like Email Forwarding and Defensive Registration).  This is 
> based on the extensions registered in the EPP Extension Registry 
> (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).  

There are unfortunately a very small percentage of all extensions that exist...
Current version of my client knows about 145 different EPP namespaces...
And I am willing to bet that there are in fact more than 200 in the wild.

As written above, I have no idea how to do an EPP client capable of
validating all of them.

> With the exception of the RGP Poll Mapping and the Low Balance Mapping, 
> the poll messages are associated with actions that the client previously 
> took, so it’s reasonable to assume that the client supports it.

This assumptions fail completely for all the cases outlined above, specially
in ccTLDs.
There are many other exceptions in the wild besides the two you list.

One example: the registry notifing the registrar that it just deleted one of its contact or host because it became unlinked and obsolete after some policy delay...

> Since it looks like Patrick and I are most likely at an impasse, I ask 
> the list to weigh in on the two options that include:

I disagree. We are not at an impasse. You see a problem and wish to resolve it by some solution. If you are motivated to defend it, write a draft and let the WG consensus build itself on it, if it reaches other interests.
I am certainly not here to say not to do it.

I have no counter proposal to yours since my solution is basically "do nothing", as the status quo, while not perfect, seems good enough to me or at least best than the solution we speak here about. But of course it would help if registrars specially come and share their experiences and "wishlist".

So, feel free to go forward with a draft if you like. 

>   2.  Server considers the login services and filters non-supported 
> extensions (object and command / response) from the poll message 
> response with an encoded <msgQ><msg> indicating the extension namepaces 
> not supported.  

This also raises an another important problem, partially depending on policy.
Let us imagine the registry starts some new notification messages under a new namespace (or, less radical: just changes some namespace version).
At the exact moment this happens all currently logged in clients, as well as all future clients not having been updated will know nothing about this namespace hence, per your proposal, the server will filter out these messages.

Where will these messages go? If they are lost for good it is bad as the registrar will have no way to know that (except parsing in a new way the msg element, which involves updates), at all. Even maybe no way to know it needs to be updated (whereas if it started to receive new messages it would just see the new namespace and could act or error on it, but at least decide itself what it wants to do). Maybe the client will just get updated hours or days later, but even in any tiny timeframe some messages may come like that and be lost forever... (the registrar can not necessarily wait on the first of such message by not acknowledging it until it gets updated, because this will block it from retrieveing the following ones, that may contain even more important information for its business). I think this is taxing registrars too much.

You suppose also that the registrars will get updated to parse the new <msg> format: this is an assumption that can break.

Filtering messages at the server side seems creating more problems than solutions to me.
This is tied to the problem of sitting messages not being acknowledged by the registrar. Some registries are then sending them by email for example after a certain delay to be able to purge the queues.
I know others where there is no purge and you can find messages almost 10 years old...
(the usefulness of such messages now is seriously debattable...)
But at least not just filtering some out and making them disappear definitively.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 20 Apr 2018 14:06:11 +0000

Patrick,

Thank you for the detailed description of your reasoning.  I will leave it that we disagree on the purpose of the login services, the need for the server to honor the login services for poll messaging, and the impacts in returning unsupported responses or response extensions to clients.  On the impact, there are two elements to consider including first the XML parser in validating a response against the XML schemas, and second is the unmarshalling of the XML to a representative object.  A client could disable the XML parser validation and move along to the unmarshalling step.  In the unmarshalling step the client would need to deal with receipt of unsupported content.  The client could throw an exception because the XML (e.g., DOM tree) could not be unmarshalled, ignore the unsupported content, or come up with some other representation of the unsupported content (e.g., convert to list of XML blobs or DOM objects).  A client would need to proactively deal with the unexpected if the server does not honor the login services of the client.  With the inclusion of the greeting and login services, it seems clear to me that the intention of the protocol is not to have the clients deal with the unexpected.  

Since this is not a problem unique to draft-ietf-regext-change-poll, I agree that it's best suited to be addressed in a separate Internet Draft that addresses service-aware EPP poll messaging.  Is there interest in such a draft by the working group?  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 
On 4/20/18, 1:58 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    Text says:

    

    

    

    

    

    

    

    

    

    

    
    
    -- 
      Patrick Mevzek
      [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 22 Apr 2018 21:26:52 +0200

On Fri, Apr 20, 2018, at 16:06, Gould, James wrote:
> Thank you for the detailed description of your reasoning.  I will leave 
> it that we disagree on the purpose of the login services, the need for 
> the server to honor the login services for poll messaging, and the 
> impacts in returning unsupported responses or response extensions to 
> clients.

Ok.

> On the impact, there are two elements to consider including 
> first the XML parser in validating a response against the XML schemas, 
> and second is the unmarshalling of the XML to a representative object.  
> A client could disable the XML parser validation and move along to the 
> unmarshalling step.  In the unmarshalling step the client would need to 
> deal with receipt of unsupported content.  The client could throw an 
> exception because the XML (e.g., DOM tree) could not be unmarshalled, 
> ignore the unsupported content, or come up with some other 
> representation of the unsupported content (e.g., convert to list of XML 
> blobs or DOM objects).  A client would need to proactively deal with the 
> unexpected if the server does not honor the login services of the 
> client. 

Your description still leaves out a case, that I can not prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one.

In this case, there are absolutely none of the problem you expose:
the registry has no extra work to do, the registrar has no extra work to do to understand messages in unknown namespaces, registrar is not blocked at all for any new namespace introduced, the registrar has no problem if the registry message does not validate per its own XML schema, the registrar does not have to be proactive it can deal with new cases and problems later, etc.
I really fail to see the drawbacks but of course anyone is free to do differently and stick to validate and parse everything in band in real time.

As for "A client would need to proactively deal with the 
unexpected if the server does not honor the login services of the 
client.", I think this is already the case for many registries, and since a long time, so clients had to deal with that already. It is far from a new hypothetical problem.

> Since this is not a problem unique to draft-ietf-regext-change-poll, I 
> agree that it's best suited to be addressed in a separate Internet Draft 
> that addresses service-aware EPP poll messaging.

I agree this should be a separate draft, to become eventually an Informational Standard or a Best Practice depending on its content.

> Is there interest in such a draft by the working group?  

I am interested by the subject but disagree on the offered solution.

Also, it may be useful to be able (as difficult as it may be) to understand a little more on the current situation, and to see how registries currently handle this problem.

Note that this happens very early and not only from poll messages.
If the registrar logs in without the secDNS extension, to use a "core" example, and if it does a domain:info on a domain name which has secDNS info (because it is one of his own domain for which he put DNSSEC material with it before but right now in this particular session it did not use the secDNS extension at login, or maybe less contrived before a transfer he does a domain:info with the associated authInfo on a domain name it does not sponsor)
then what should the registry do? Send the secDNS part of the domain:info or not?
I believe not sending it creates more harm than benefits, even if the registrar did not specify it at login, but clearly this is the core point of our disagreement.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Apr 2018 13:27:39 +0000

Patrick,

This may be an excellent topic for a working session at the next IETF.  It would be great to hear opinions from others on this topic, since there is obviously a gap in the interpretation of the greeting and login services as it relates to responses (command responses and poll response) provided by the server.

Your description still leaves out a case, that I cannot prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one.

How can the client ack the message if it doesn’t at least parse it for the message id?  An EPP client should frame the responses per RFC 5734 and will most likely parse the response to determine the result of the command and in the case of a poll message parse the message id to send the subsequent poll ack.  The client could use regular expressions to extract the information or could do a validating DOM parse and object unmarshalling to have something easier to work with.  There is no way for the server to know the capabilities of the client other than using the login services.  Both sets of clients can be fully supported if the server honors the login services sent by the client.  If the client wants to retrieve everything from the server for later processing, then the client can simply mirror the greeting services into the login services.  Clients that do unmarshall responses, will most likely use marshalling factories that will be used to dynamically create the login services.  This way the server will not send a response that the client does not support and will not break the client.

Just because servers have been sending unsolicited extensions to clients does not make it correct or appropriate from a protocol perspective.  I believe we have examples of EPP extensions (RFC 5910 and draft-ietf-regext-epp-fees) that includes language related to what the server should or should not due based on the client login services, so this should be understood.  I believe where it is not well understood is the handling of poll messages, which would be the point in creating a new draft.

The registry should not return the secDNS extension in the domain info response for a client that does support secDNS-1.0 (RFC 4310) or secDNS-1.1 (RFC 5910) according to section 2 of RFC 5910 (https://tools.ietf.org/html/rfc5910#page-4).  There is similar language in the Registry Fee Extension related to inclusion of the fee extension in the command response (e.g., “does include elements in the response, when the extension has been selected during a <login> command”).  The login services explicitly provide the object and command / response extensions supported by the client along with their versions, so why would the server not honor those services to determine if and what version of an extension to return to a client?  The exchange of the server services in the greeting and the client services in the login allow the client and server to negotiate what extensions are supported on both sides.  Inclusion of an extension outside of the negotiated services should result with an error on the server side and the server should not return an unsupported extension back in a response.  The server does not know the capabilities of the client, where sending an unsolicitated extension may result in a client-side failure in the case for a validating client or a client that unmarshalls the response.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/22/18, 3:27 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Ok.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]