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
jgo...@verisign.com
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"
<regext-boun...@ietf.org on behalf of p...@dotandco.com> 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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
