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 jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/21/18, 12:12 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: 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. > 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. 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 _______________________________________________ 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
