Hi Maarten,
please find a comment inline prefixed with [ML].
Il 17/03/2026 07:25, Maarten Wullink ha scritto:
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: 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?
[ML] This is partially covered in the Security Cosiderations section.
However, we can be more precise by slightly rephrasing the sentence:
OLD
Finally,
servers are RECOMMENDED to perform additional checks to limit the
rate of open EPP sessions and HTTP connections to mitigate the risk
of congestion of requests
NEW
Finally,
servers are RECOMMENDED to perform additional checks to limit the
number and rate of open EPP sessions and HTTP connections to mitigate the
risk
of congestion of requests and resouce exhaustion.
However, the risk of managing too many sessions or maintaining unused
sessions is common to all mechanisms based on server-generated secrets
to prevent clients from authenticating on every request. To be clear,
EoH sessions = RPP JWTs.
The mitigation measures are the same: limit the number of simultaneously
active secrets and optimize secret lifetime.
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]
<mailto:[email protected] <mailto:[email protected]>>>
To unsubscribe send an email to [email protected]
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]
<mailto:[email protected]>>>
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
