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

["Gould, James" <[e-mail]>]

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

[e-mail]



703-948-3271

12061 Bluemont Way

Reston, VA 20190



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



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



    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



    _______________________________________________

    regext mailing list

    [e-mail]

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