Hi Jim, Here is my response to the issues where you disagree.
A HTTP session MUST be linked to an EPP session, therefore the session should only be created, and cookie set after successful login command. Cannot have a HTTP session without linked EPP session. JG-Incorrect, the HTTP session is strictly used to maintain a statement EoQ connection and is not associated with the authentication a successful login command." Would it help for us to the commonly used terms like what was done in the Introduction of draft-ietf-regext-epp-quic, which would include EoH, EoH connection, and EoQ session. It’s the EoQ session that maps to a successfully established EPP session. The EoQ connection is associated with a successfully established EPP connection, which is realized by establishing the statement HTTP session in the HTTP GET. MW: My comment was about the EoH draft, your response seems to be about EoQ? I did not read the EoQ draft yet because i'm not a QUIC expert. My point is: why have a session without a linked EPP session? JG-See my response about the HTTP session above. The HTTP session is not mapped to the EPP session, but to the EPP connection. The GET response must include the EPP greeting to comply with the EPP server state machine, defined in section 2 of RFC 5730. MW: i don't get this, why map HTTP session to EPP connection and not EPP session? or are you describing a proxy-like situation where the HTTP server creates EoT connections to remote EPP server vs having the whole EPP logic run on the HTTP server? "An EPP session is normally ended by the client issuing an EPP <logout> command. this assume there will always be clean logout, better would be to assume the client never sends logout command. Here is disconnect between HTTP and EPP sesion l JG-There is no assumption of a clean logout, but that is considered the recommended or normal method. The unclean termination is covered in the following sentence. "A server MAY also end an EPP session that has been either active or inactve for longer than a server-defined period" MW: also remarked this in other mail to list, maybe add line to security considerations about resource exhaustion when too many sessions are created? this is a workaround because of the architectural mismatch between HTTP and EPP session. JG-EPP already has a mismatching between the EPP connection and the EPP session. A client can establish an EPP connection and simply send an EPP <hello> without ever submitting the EPP <login>. That's sort of pointless but demonstrates the separation of the EPP connection and the EPP session. Once the EPP session is established, the termination of the EPP session via the EPP <logout> command will terminate both the EPP session and the EPP connection. The use of inactive timeouts (idle timeout) is common practice for EPP to deal with stale EPP connections / sessions established by the client. There is really no difference between EoH and EoT in this case. MW: Yes, that's a good point about starting EPP connection and never doing login. However, when running the EPP logic purely inside the HTTP server, the concept of a EPP connection does not exist anymore. Then it does not seem correct to still map HTTP session to EPP connection. " An EPP server MUST return an EPP response to an EPP command in the HTTP response to the respective HTTP request." I had to read this sentence 3 times to understand it, maybe rewrite to: An EPP server MUST return the EPP response within the HTTP response for a request? JG-I believe the intent here is that there is a mapping of the EPP command with the HTTP request and the associated EPP response with the HTTP response. The EPP commands are processed in order, which means for EoH, every EPP command is embedded in the HTTP request and the EPP response is embedded in the associated HTTP response. How about " An EPP server MUST embed the EPP response in the associated HTTP response to the HTTP request containing the EPP command."? MW: I propose slight tweak: "An EPP server MUST include the EPP response in the message body of the HTTP response to the HTTP request containing the EPP command." Client is maybe not the correct term here, a client can start multiple active HTTP sessions. command order should be enforced at the session level not client level. JG-We could change this to read "Command MUST be processed independently and in the same order as received on the EoH connection." Does that help? I was thinking that commands should be processed in order based on the session, but that's not possible just ignore the original comment please. "Servers MUST return an EPP 2002 response (i.e. Command use error) if the client issues an EPP command with either an empty or an invalid HTTP session identifier." Only for HTTP POST requests is probaly meant here? JG-In thinking about this more, I believe if the server receives an EPP command via the HTTP POST without the required HTTP session identifier, the command MUST NOT be processed, and the HTTP 400 "Bad Request" is returned. This is a failure at the transport layer and not the application layer. Do you agree? MW: It's a client error at HTTP level, so yes 4xx code would be applicable. "The EPP transport described in this document should be registered by IANA in the Extensions for the Extensible Provisioning Protocol" A new EPP transport is not an EPP extension, it is clearly described differently in RFC5730 and is never event mentioned in RFC3735 (Guidelines for Extending the Extensible Provisioning Protocol (EPP)) JG-I believe the EPP transport is a form of extensibility, which in my mind is an extension defined within RFC 5730. I don't believe my interpretation will pass consensus, so we may go with Pawel's proposal of creating an EPP transports IANA registry. Do you agree with Pawel's proposal? MW: That should work _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> To unsubscribe send an email to [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
