Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

From: "James Galvin" <[email-masked]>
Date: Fri, 04 May 2018 09:31:50 -0400

The chairs would appreciate a suggestion from those in this discussion 
as to what you would like to do next?

The change-poll document has been in WGLC that has now expired.  
However, you have identified a technical issue but you have not been 
clear as to whether you want a change in the existing document or you 
want a new work item for the working group?

What would you propose?  What do others think?

Antoin and Jim

On 23 Apr 2018, at 9:27, Gould, James wrote:

> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
> 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
>
>
>
> Verisign.com <http://verisigninc.com/>
>
> On 4/22/18, 3:27 PM, "regext on behalf of Patrick Mevzek" 
> <[email-masked] on behalf of [email-masked]> wrote:
>
>
>
>     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]
>
>
>
>     _______________________________________________
>
>     regext mailing list
>
>     [email-masked]
>
>     https://www.ietf.org/mailman/listinfo/regext

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Fri, 4 May 2018 14:15:32 +0000

Jim,

My recommendation is to move forward with draft-ietf-regext-change-poll and to leave the EPP server sending unsupported responses (mapping extension and / or command response extensions) to a client based on the login services up to a separate draft.

This comes down to the interpretation of how the server should handle the login services of the client in creating responses.  EPP extensions like the DNSSEC extension (RFC 5910) leverages the login services in the migration from RFC 4310 to RFC 5910, since the info response may include the DNSSEC extension if there is DNSSEC data.  The inclusion of the DNSSEC extension and the version of the DNSSEC extension is based on the login services.  Similar functionality exists within draft-ietf-regext-epp-fees in determining if and which version of the extension to return to the client.  Poll messages are unique since they are inserted ahead of time by the server without knowledge of what the client does support, and therefore runs the risk of coming across a message that the client does not support based on the login services.  Clients may or may not be able to handle the parsing and unmarshalling of unsupported extensions sent by the server.  For poll messaging this is of particular interest, since a client may have an issue acknowledging the unsupported poll messages to get to the rest of the messages in the queue.  This would represent a poison message in the poll queue.

Based on the thread, there are separate thoughts related to whether it is fine for the server to send a response that contains an extension that was not included in the client’s login services.  I believe that the greeting services and the login services are used to negotiate the set of extensions that client are server can use.  What should the EPP server do with unsupported extensions in any EPP response and with poll message EPP responses in particular?  This is a broader topic than draft-ietf-regext-change-poll, so I recommend that we don’t attempt to solve the problem specifically for draft-ietf-regext-change-poll but more generically across all of the extensions in a separate draft.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>
From: James Galvin <[email-masked]>
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould <[email-masked]>
Cc: Patrick Mevzek <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

The chairs would appreciate a suggestion from those in this discussion as to what you would like to do next?

The change-poll document has been in WGLC that has now expired. However, you have identified a technical issue but you have not been clear as to whether you want a change in the existing document or you want a new work item for the working group?

Antoin and Jim

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.

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.

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.

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.

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:

    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

    Ok.

    > 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,

    > 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

    > 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.

    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.

    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.

    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]

    regext mailing list

    [email-masked]

---

From: Roger D Carney <[email-masked]>
Date: Fri, 4 May 2018 18:27:52 +0000

Good Afternoon,

+1.

We agree that that we should move forward with the current draft-ietf-regext-change-poll draft and move this discussion along another path.

Thanks
Roger

From: regext [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Friday, May 04, 2018 9:16 AM
To: James Galvin <[email-masked]>
Cc: Patrick Mevzek <[email-masked]>; [email-masked]
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

Jim,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>
From: James Galvin <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Patrick Mevzek <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

Antoin and Jim

Patrick,

—

JG

James Gould

Distinguished Engineer

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

    Ok.

    --

      Patrick Mevzek

      [email-masked]<mailto:[email-masked]>

    regext mailing list

    [email-masked]<mailto:[email-masked]>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: Pieter Vandepitte <[email-masked]>
Date: Tue, 8 May 2018 16:21:57 +0200

I agree: move on, and make this discussion a new work item for the group.

It was an interesting discussion by the way... 

My opinion: 

First of all, I don't know about real world examples of issues concerning unsupported extensions by one of our registrars. When we introduce new extensions, or update existing ones, this is all communicated long in advance to all of our registrars so they can prepare the change. They have plenty of time to implement the extensions, and if they don't implement them, I guess they just ignore it (non-validating clients). There's no such thing as a client which all of a sudden must support or handle new extensions. 

Now to answer the questions:

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?

No. As Postel said: "be conservative in what you do". The client says it does not understand it, so be kind and don't return it.

2. The purpose of the server's greeting service and the client's login services: 

It's not a negotiate. It's informational, and in case of the login svcs it's a kind request to only "talk the languages" of the supported extensions. Should a server return an error when it receives a request containing extensions it does understand, but which are not mentioned by the client? No, even not for extensions it does not understand.

3. Validating clients: clients should be permissive in what they accept. A client must interpret the server's response as good as possible (i.e. ignoring XSD violations, use of non-supported schema's, ...).

What about poll responses potentially containing extensions not supported by the client? Because of (3) that should not be a problem, but since in my opinion a server should be conservative (to be able to serve both validating and non-validating clients), it should send the response in another way. This is in my opinion a task for the working group. (Top of mind suggestion: encode part of the response which is not understood as a CDATA block)

kind regards

Pieter

> On 04 May 2018, at 20:27, Roger D Carney <[email-masked]> wrote:
> 
> Good Afternoon,
>  
> +1.
>  
> [email-masked] <x-msg://4/[email-masked]>
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> From: James Galvin <[email-masked] <mailto:[email-masked]>>
> To: James Gould <[email-masked] <mailto:[email-masked]>>
> Cc: Patrick Mevzek <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> The chairs would appreciate a suggestion from those in this discussion as to what you would like to do next? <>
> 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 <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] <mailto:[email-masked]>
>  
> 
> 703-948-3271
> 
> 12061 Bluemont Way
> 
> Reston, VA 20190
> 
>  
> 
> Verisign.com <http://verisigninc.com/ <http://verisigninc.com/>>
> 
> On 4/22/18, 3:27 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked] <mailto:[email-masked][email-masked]>> wrote:
> 
>  
> 
>       [email-masked] <mailto:[email-masked]>
>    
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>
>    
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>_______________________________________________
> regext mailing list
> [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 21 May 2018 05:57:48 +0200

On Fri, May 4, 2018, at 16:15, Gould, James wrote:
> My recommendation is to move forward with draft-ietf-regext-change-poll 
> and to leave the EPP server sending unsupported responses (mapping 
> extension and / or command response extensions) to a client based on the 
> login services up to a separate draft.

I completely agree with this split.

The problem that was discussed after this draft has in fact nothing to do in its core with poll messages, the issue, if there is one, is more global than that. I will try to expose it in another email.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 21 May 2018 06:12:08 +0200

On Tue, May 8, 2018, at 16:21, Pieter Vandepitte wrote:
> There's no such thing as a client which all 
> of a sudden must support or handle new extensions. 

Probably because the intersection of
"clients validating absolutely all EPP frames received by registry"
and
"clients using blindly all extensions as announced by registry on greeting"
is nil.

However you may not have seen this case or not have been in one, but, for having been in one, I know it exists case where the registry says: at day X you can not connect anymore to the EPP server if you do not use on login namespace X and are prepared to receive messages with it.

Then you are just resolving the problem we discuss by moving it into business-land: saying to the registrars to upgrade and thinking that you then can send messages with the new extensions because you are sure they will be able to handle it because they selected it on login...
Maybe they instead just did a quick change to alter the login (specially if it the case of just one extension going from version A to B) and did not bother implementing things further than that

> The client says it 
> does not understand it, 

That is not exactly the meaning I read from the login part. I am more reading it "I will not deal with this extension, I will not use it in my messages". See my following messages for an example.

> It's not a negotiate. It's informational, and in case of the login svcs 
> it's a kind request to only "talk the languages" of the supported 
> extensions. Should a server return an error when it receives a request 
> containing extensions it does understand, but which are not mentioned by 
> the client? No, even not for extensions it does not understand.

We are now talking about the opposite case (what messages from the client should the server accept) and here I disagree with you: the client clearly designates at login which namespaces it want to handle, so the server should never accept messages with other namespaces from the client. This is also being conservative and helps defeat errors in the client. I know at least one registry server behaving exactly like that.

> 3. Validating clients: clients should be permissive in what they accept. 
> A client must interpret the server's response as good as possible (i.e. 
> ignoring XSD violations, use of non-supported schema's, ...).
> 
> What about poll responses potentially containing extensions not 
> supported by the client? Because of (3) that should not be a problem, 
> but since in my opinion a server should be conservative (to be able to 
> serve both validating and non-validating clients), it should send the 
> response in another way.

This opens a new complete can of worms. Some registries send then emails, others give messages by HTTPS connections, etc.
Many things outside of EPP since I believe that based on the constraints you pose there is noway to resolve that inside EPP.

And BTW being liberal here does not impact negatively validating clients: when seeing a namespace, they can validate it conforms to a schema even if they do not really care of its content and do not use it.

> This is in my opinion a task for the working 
> group. (Top of mind suggestion: encode part of the response which is not 
> understood as a CDATA block)

I am in general completely against the idea of encapsulating one formatting inside another, as the idea was already suggested (changing the pure textual message by adding some formatting in it). Hence I would really not think that using a CDATA block is a good idea.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 21 May 2018 07:14:31 +0200

> This may be an excellent topic for a working session at the next IETF.

If there is interest, yes...

For now I think only you, me, and Pieter said anything in this discussion.
So again maybe there is a real problem to tackle and then you need to foster participation, or there is no real problem to tackle any more because people already found out solutions. Since our resources are thin and participation low, I just want to make sure that no work starts before making sure it really address a problem shared by more than one party.

> there is obviously a gap in the interpretation of the greeting and login 
> services as it relates to responses (command responses and poll 

It would be, yes.

Also, in the meantime, people could report how they current software reacts, this would at least give some factual data.

Speaking about what I know directly, because I worked on them and to the best of my recollection from those in the past:

1) my open source EPP client on login either mirrors all extensions given by registry (handling the case of the same extension in multiple version to select only the highest one) or specifically use only extensions requested by the application using the library; it does not validate EPP frames received from registries (for pragmatic reasons, and some people could say also for performance ones); for results of poll command, it will parse what it can based on the extension locally registered and let the calling application deal with others if it wants (it has access to both the parsed message and its raw complete form)

2) another proprietary client used on the field by a registrar for multiple registries: it does login only with the specific extensions implemented locally, it does not validate messages received, it stores poll results in a DB without any attempt to parse them in any way, and just acks them; other processes completely outside of EPP takes care of parsing the relevant part of the messages stored in DB.

3) as for a proprietary server, it checks what namespaces are used for each subsequent messages and that they correspond to namespaces selected at login (erroring otherwise); it does not validate XML messages on input or output; it does not reply in domain:info with namespaces not chosen by client but it does not filter them out in registry notifications.

> How can the client ack the message if it doesn’t at least parse it for 
> the message id? 

The message ID is in the core EPP, it has nothing to do with any specific EPP extension that may have been used in the message itself.
I am sure you know that, so I may have taken a too short summary in my previous message.

> An EPP client should frame the responses per RFC 5734 
> and will most likely parse the response to determine the result of the 
> command 

You are again it seems only thinking about poll results being messages resulting from past actions of this registrar. There are other ones like:
- transfers, when the registrar looses a domain (so clearly not due to one of its action)
- registry warning about contacts being deleted after not being used
- registry warning about account balances,
etc.

The last two are specific examples today of basically being messages formatted in different ways in each registry as there is no standard covering them.

And the result of the action could be conveyed by the data already in the panData node, irrespective to other specific extensions used to further describe the content of the message.

> 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. 

This is not always possible in reality, for at least this specific example that it is not imaginary since it derives directly from two known cases.

This will also serve to illustrate that the problem is not really or not only with registry notification messages in fact, but that you have the exact same problem with a result of a domain:info for example
(note that I am not claiming there is always one and only one good way to do things, and I am not sure a standard could be written on this, something closer to a guidance document that specifies the pro and cons of each case and at least mandate that registries clearly specify in which case they are)

1) Some registries treat DNSSEC very separately and mandates their registrars to be separately accredited for it. So it is optional, and some registrars may decide not to conduct it (as strange as it may seem I know some registrars are philosophically against DNSSEC, and not only for business reasons, and those ones, even if mandated by a contract to do DNSSEC, will still refuse to do it. Sad, maybe, but that is on the field today).
The EPP server will most probably offer the exact same greeting to all clients.
However, upon receiving the login, it will probably refuses to accept clients not being DNSSEC accredited present a login with a secdns extension.

2) Now imagine one of such reluctant registrar. It does not want to deal with DNSSEC in any way, because it has its reasons. Even if there would be no specific needs to be accredited so nothing special to do to be able to use the extension at login, since it does not want to handle it at all, it will never use the secdns extension at login. His choice.

But you will probably also note that the most reluctant folks against DNSSEC are often very technically minded ones. Especially in EPP land, people know that DNSSEC and transfers do not play well together (keyRelay is a standard but is there anyone else than SIDN using it today? plannig to use it in the next year?)
So you may have one registrar against it but also wanting to play nice to its customers: it wants to make sure never to accept an incoming transfer of a domain that is currently using DNSSEC because it does not handle it himself so the transfer at its core will just horribly break the zone.

Now what happens if it does a domain:info for such a domain previous to the transfer (with the associated authInfo as being done by multiple registries): it either has the secDNS:infData (because the registry sends everything) or it has not, even if it exists for the domain (because the registry filters messages based on extensions provided at login).

In the first case, with the "extra" data being there the registrar can detect that the domain is DNSSEC enabled and refuse to start the transfer (it could of course also query the DNS to find out about the DNSSEC exiting on the domain or not, but this may not exactly fit an EPP based workflow), making him nice and its customer happy as the zone will not get broken.

Or the extra data is not there and the registrar does the transfer and the zone is broken.

So here is an example that needs to be taken into account. Again I am not saying this is clear cut with a clear good option and a clear bad one. I think both positions have merits. This is the only purpose of my participation in the discussion, to try showing more of the global picture to really think about all cases, and their consequences.

> Just because servers have been sending unsolicited extensions to clients 
> does not make it correct or appropriate from a protocol perspective.

This issue being debated right now, and since there is 0 documents currently saying anything specifically on this, it would be quite inappropriate (and clearly not a good way to bring everyone around the table) to already label some servers being incorrect or inappropriate.

>  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.

I still think the problem is larger than that, and not as clear cut as presented. IF the problem exists, it must be dealt globally and must not need text about it in each extension.

> point of our disagreement.

Note that I am not fully convinced by either position in fact.

For now I am just saying:
- the problem is more complex that just registry notifications
- each case has benefits and drawbacks
- the problem may already have been solved and/or the registrars may not care to revisit the issue now

> (https://tools.ietf.org/html/rfc5910#page-4). 

Section 2 specifically handles the problem of transitioning from secDNS-1.0 to secDNS-1.1 so for now I fail to see how it is relevant to our discussion here.

> 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.

The exact same problem exists in the opposite case. 
I am fine you disagree with me but I am not sure if you accept to see there are other cases where, using your interpretation, creates problems too. So it is not clear cut, and no solution resolves eerything.
If work is engaged on this topic I think there is first a need to clearly define the problem statement, what cases exist today, what solutions may be implemented and their consequences.
Only after that we could have a discussion on the merit of each solutions.
But if we even disagree on the problem itself and the use cases that exist, then I will probably not be able to participate in the following discussion either.

I was happier when you wrote in one of the first messages on the issue:
" 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."

There we agree, there is no great solution. So let us now not decide for a solution before even having explored all the problem space (or agree on its scope). Experiences here specifically from other registrars would be very useful.

Again, don't you feel it strange that this issue has never been brought and discussed extensively before, during the nearly 20 years that EPP now exists?
This does not mean of course there is not a problem, but then even more than elsewhere I fear very low level of participation from registrars...

PS: just thinking more globally, please also take into account this example. A registrar connects at some time with extension X from the one offered by the registry. It does some operations through this connection and let us imagine that one of this operation triggers the *future* creation of a registry message that will use extension X. But through this connection the registar does not do a poll operation at all. Later the registar does another connection from scratch, this time without the extension X. It does a poll. What happens for the registry notification that had the X extension? You do not deliver it at all to the registar and block its queue? You deliver it completely, even with X? You deliver it while removing the X part, loosing it forever? Etc.
No great solution either here. This needs to be documented before any attempt to solve
(and again I do not believe it will be possible to find a solution that fits all cases, at best a guidance document clearly describing things, and suggesting things maybe at most, not mandating one case over another)

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 21 May 2018 14:15:26 +0000

Patrick,

I believe the goal here is to discuss the protocol itself and not deal with the registry or registrar policies that conflict with it.  

The EPP greeting per RFC 5730 "identifies the services supported by the server".  The EPP login command services per RFC 5730 includes "<objURI> elements that contain URIs representing the objects to be managed during the session" and "MAY contain one or more <extURI> elements that identify objects extensions to be used during the session".  I don't view the services included in the greeting or the login command as information, but used to negotiate the object and extension services to be used by the client and server during the session.  The client must not pass services that the server does not support based on the EPP greeting services, and the server must not pass services that the client does not support based on the login command services.  With this in place, the server can make decisions on what it will return the client based on what the client support.  There should be no assumption that clients can receive and consume responses that include services that the client did not include in the login services.  A client that is capable of accepting every possible services in the response can simply mirror the greeting services in the login services.  Clients that are only capable of supporting a subset of the services should reflect that in the login services.  If we come to agreement on the meaning of the greeting and login services then we can move onto the question of handling poll messages that contain services that may not be supported by a client.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

    

    

    

    

    -- 
      Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 22 May 2018 09:24:45 +0200

On Mon, May 21, 2018, at 16:15, Gould, James wrote:
> The EPP greeting per RFC 5730 "identifies the services supported by the 
> server".  The EPP login command services per RFC 5730 includes "<objURI> 
> elements that contain URIs representing the objects to be managed during 
> the session" and "MAY contain one or more <extURI> elements that 
> identify objects extensions to be used during the session".  I don't 
> view the services included in the greeting or the login command as 
> information, but used to negotiate the object and extension services to 
> be used by the client and server during the session.  The client must 
> not pass services that the server does not support based on the EPP 
> greeting services, and the server must not pass services that the client 
> does not support based on the login command services. 

James,

Just repeating the same interpretation of some text in order to come to the same conclusion as the preferred one without wanting to see other points in the global picture is a sure way to close the discussion, and not to open it.

> A client that is capable 
> of accepting every possible services in the response can simply mirror 
> the greeting services in the login services.

Read my messages. You have examples when this does not correspond to reality.

It is fine having only one implementation in mind and defining stuff to conform to it but, sorry, there are others, and other use cases too.

>  If we come to agreement on the meaning of the 
> greeting and login services then we can move onto the question of 
> handling poll messages that contain services that may not be supported 
> by a client.

I think you are putting the cart before the horse. Like I said multiple times the problem, if it exists (as I am not sure it exists), must first be clearly specified, taking into account all use cases. Only after that we can discuss on how to read the current documentation and see what the conclusions are.

Starting by interpreting the text to come to a favorable conclusion is not really trying to discuss or come into agreement or consensus in my mind.

But again, I think we rehashed this point often enough now, so besides some specific document to discuss, or other new views to exchange, it may be better to let the thread die.

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Tue, 22 May 2018 12:23:50 +0000

Patrick,

Referring to the language in the RFC is the starting point in the discussion related to defining the problem that may or may not require a solution.  I disagree that we should look at the various implementation policies implemented in the wild by registries and registrars to develop the appropriate interpretation of the RFC.  I see three options with the interpretation of the RFC:

  1.  There is no problem
     *   The RFC supports servers returning services that the client does not include in the login services.  This includes responses to object commands (e.g., domain create) and poll messages.
  2.  There is a problem, but it is not important enough to create a common solution
     *   The RFC does not support servers returning services that the client does not include in the login services, but it is not important enough to the clients to define a common solution.  It’s pretty straight forward for the server not to return an extension in the response to an object command (e.g., domain create), so the real problem is associated with the poll messages.
     *   With this option, no common solution will be defined for the handling of poll messages that the client does not support based on the login services.
  3.  There is a problem and a common solution is required
     *    The RFC does not support servers returning services that the client does not include in the login services and a common solution is required.  It’s pretty straight forward for the server not to return an extension in the response to an object command (e.g., domain create), so the real problem is associated with the poll messages.
     *   With this option, we can start the discussion on defining a common solution for the handling of poll messages that the client does not support based on the login services.

I believed I jumped to a proposal for a common solution without determining whether the problem is important enough to address.  I do not agree with option 1 based on what is defined in RFC 5730, so it comes down between option 2 and 3.

Any thoughts on these options or other options?

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

    James,

    --

      Patrick Mevzek

    regext mailing list

    [email-masked]

---

From: Thomas Corte <[email-masked]>
Date: Tue, 22 May 2018 14:33:31 +0200

Hello,

On 5/22/18 14:23, Gould, James wrote:

> Patrick,
> 
> Referring to the language in the RFC is the starting point in the
> discussion related to defining the problem that may or may not require a
> solution.  I disagree that we should look at the various implementation
> policies implemented in the wild by registries and registrars to develop
> the appropriate interpretation of the RFC.  I see three options with the
> interpretation of the RFC:
> ...
>      1.  The RFC does not support servers returning services that the
>         client does not include in the login services and a common
>         solution is required.  It’s pretty straight forward for the
>         server not to return an extension in the response to an object
>         command (e.g., domain create), so the real problem is associated
>         with the poll messages. 
>      2. With this option, we can start the discussion on defining a
>         common solution for the handling of poll messages that the client
>         does not support based on the login services.
> 
>  
> 
> I believed I jumped to a proposal for a common solution without
> determining whether the problem is important enough to address.  I do not
> agree with option 1 based on what is defined in RFC 5730, so it comes
> down between option 2 and 3. 

I agree with option 3 only. Our registrar client systems use a validating
parser for registry responses, and it's always a major pain to fix issues
when unexpected XML namespaces start showing up.

That being said, for some registries (such as Afilias) it seems to be a
challenge to even produce schema-compliant server responses when it comes
to the standard EPP RFC schemas.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: [email-masked]
Germany

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 24 May 2018 06:23:40 +0200

> discussion related to defining the problem that may or may not require a 

If everything is already crystal clear  from the existing documents I do not know why you even presented 4 different options at the beginning of the thread.
So if everything is clear, there are no options, and no problem to solve either.
I can hence leave this conversation where it is.

> I disagree that we should look at the various implementation 
> the appropriate interpretation of the RFC.

Which is absolutely not what I said.

So I will stop here, as I may be doing more harm than benefits to the WG by continuing.

Regards,

-- 
  Patrick Mevzek

---

From: Martin Casanova <[email-masked]>
Date: Thu, 24 May 2018 10:31:08 +0200

Hello

Sorry I have not been checking the mails of this mailing list for a while...

In my opinion as registries we have a special role and should stick to
the RFC’s as close as possible for a strong EPP standard everybody can
rely on. Therefore I find it valuable to discuss the RFC’s and get
everybody's input.

I think that there is an issue with potentially breaking some clients,
although for some clients it may not be a problem as was pointed out.

Also I don't see a big problem for clients to not receive full
information in a message of a freshly implemented Change Poll Extension
response since they didn't get it at all before the extension was
implemented.

The suggestion of James Gould to give a hint about the missing extension
part in the <msg> field of the poll response may be a way to go. This
filed is intended for humans and thats what we want to do: Inform a
human to prepare his client and configure the Login command accordingly
if he wants to receive the information of the extension.

However the ChangePoll Extension is not the only one we need to inform
about. How should we inform about a changes in DNSSec Data? We also
would have to indicate that the DNSSec extension should be configured in
order to include something like

<secDNS:infData
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"><secDNS:dsData><secDNS:keyTag>2371</secDNS:keyTag>
<secDNS:alg>13</secDNS:alg>
<secDNS:digestType>2</secDNS:digestType>
<secDNS:digest>F991B7FDE40A2C4CD7BEFBBE9A1073D1FC3E34EC6DC31E2931320D1CD8392390</secDNS:digest>
</secDNS:dsData>
</secDNS:infData>

in the extension part..

We are planing to do something like this as we are going to implement
the RFC-8078 / RFC-7344 CDS feature. Of course there will also be an out
of band communication with our registrars about this.

Martin

--  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
[email-masked], www.switch.ch 
 
Working for a better digital world