SIDN / ietf-epp-restful-transport

RESTful transport for EPP
Other
3 stars 4 forks source link

Query command extensions #57

Open pawel-kow opened 3 months ago

pawel-kow commented 3 months ago

EPP allows for extending query commands as well. Example (from IANA EPP extension repository) https://www.verisigninc.com/assets/defensive-registration-mapping.pdf: 3.1.1 EPP Command

Example <check> command:
C:<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
C: <command>
C: <check>
C: <defReg:check
C: xmlns:defReg="http://www.nic.name/epp/defReg-1.0"
C: xsi:schemaLocation="http://www.nic.name/epp/defReg-1.0
C: defReg-1.0.xsd">
C: <defReg:name level="premium">doe</defReg:name>
C: <defReg:name level="standard">john.doe</defReg:name>
C: </defReg:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>

Schema:

<!--
Child elements of the <check> command.
-->
 <complexType name="checkType">
   <sequence>
     <element name="name" type="defReg:nameType" maxOccurs="unbounded"/>
   </sequence>
 </complexType>
 <complexType name="nameType">
   <simpleContent>
     <extension base="eppcom:labelType">
       <attribute name="level" type="defReg:levelType" use="required"/>
     </extension>
   </simpleContent>
 </complexType>
 <simpleType name="levelType">
   <restriction base="token">
     <enumeration value="premium"/>
     <enumeration value="standard"/>
   </restriction>
 </simpleType>

A check in REPP was so far defined as HEAD verb, which means that all additional extension information would have to be encoded into either query parameters or headers. In both of the cases one would have to encode the whole XML into a query parameter (base64 or just url-encode) -> request URI string limit might be an issue Same for headers - also here maximum header length might be an issue.

Other option would be to have a version of query commands with body. It could be like POST /{collection}/_{command} say POST /domains/_check in this case.

Downside is that in this case servers would have to implement two ways of serving the same thing.

Same situation with command. Here GET also should not contain any body, or at least this is what http RFC would not recommend to use.

Opinions or other ideas?

mwullink commented 2 months ago

encoding the info from the extension into headers and query parameers is going to be a pain.

i don't see any other way than to also allow for the use of POST method for a query command in those cases where a payload message (from extension) has to be sent to the server by the client.

the server may also choose not to implement this by not using this extension (who uses this anyway?) or any extension that requires anything other than HEAD method for a check command.