[regext] [IANA #1393969] expert review for draft-ietf-regext-epp-ttl (xml-registry)
Dear Tim Bray, Martin Thomson (cc: regext WG), As the designated experts for the ns and schema registries, can you review the proposed registrations in draft-ietf-regext-epp-ttl-10 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/ The due date is November 22nd. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/xml-registry/ Unless you ask us to wait for the other reviewer, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] [IANA #1393970] expert review for draft-ietf-regext-epp-ttl (epp-extensions)
Dear Scott Hollenbeck (cc: regext WG), As the designated experts for the Extensions for the Extensible Provisioning Protocol (EPP) registry, can you review the proposed registration in draft-ietf-regext-epp-ttl-17 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/ The due date is November 22nd. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/epp-extensions/ With thanks, David Dong IANA Services Sr. Specialist ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] [IANA #1393970] expert review for draft-ietf-regext-epp-ttl (epp-extensions)
Hi Scott, Just to note, you last reviewed -15 and it looks like the author addressed your feedback from that review, but we will wait for your approval again. Best regards, David Dong IANA Services Sr. Specialist On Fri Nov 08 20:47:48 2024, david.dong wrote: > Dear Scott Hollenbeck (cc: regext WG), > > As the designated experts for the Extensions for the Extensible > Provisioning Protocol (EPP) registry, can you review the proposed > registration in draft-ietf-regext-epp-ttl-17 for us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/ > > The due date is November 22nd. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/epp-extensions/ > > With thanks, > > David Dong > IANA Services Sr. Specialist ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] [IANA #1393969] expert review for draft-ietf-regext-epp-ttl (xml-registry)
Hi Tim, Martin, Just to note, you had last reviewed -15, and it looks like the author had addressed your feedback from that review. Best regards, David Dong IANA Services Sr. Specialist On Fri Nov 08 20:25:58 2024, david.dong wrote: > Dear Tim Bray, Martin Thomson (cc: regext WG), > > As the designated experts for the ns and schema registries, can you > review the proposed registrations in draft-ietf-regext-epp-ttl-10 for > us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/ > > The due date is November 22nd. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/xml-registry/ > > Unless you ask us to wait for the other reviewer, we’ll act on the > first response we receive. > > With thanks, > > David Dong > IANA Services Sr. Specialist ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Clarifications on server error responses in EPP over HTTP (draft-loffredo-regext-epp-over-http )
After Jim Goulds presentation on implementing EoH and EoQ I was inspired to start hacking on the two protocols in our own EPP server implementation, while doing so, some questions about EoH popped up. In the EoH draft there is a couple of MUSTs for the client when sending a request: - The GET request MUST include "application/epp+xml" (Appendix B of [RFC5730]) in the "Accept" HTTP header. - An EPP client MUST send all commands as HTTP POST requests (Section 6.4 of [RFC9110]). - Each POST request MUST include the HTTP session identifier in the "Cookie" header and "application/epp+xml" in the "Accept" header. The current draft provides the following for dealing with misbehaving clients. Servers MUST NOT use HTTP return codes to signal clients about the failure of the EPP commands. The HTTP code 200 MUST be used for both successful and unsuccessful EPP requests. Servers MUST use HTTP codes to signal clients about the failure of the HTTP requests. 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. The only thing covered in detail is what should happen if an EoH server receives a request without a session identifier. I think it would be useful for the spec to be clear on what a server should return if any of the requirements above are broken. My 2 cents on what a server should do: - A request with the correct Accept header but wrong HTTP method (say we get a PATCH instead of a POST): A server MUST return a 405 HTTP status code - A request with the incorrect Accept header: A server MAY return a 406 HTTP status code (I guess one could think of a server that handles EPP and other stuff so MAY is probably best). // Eric The Swedish Internet Foundation ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
