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
