Agreed, based on the makeup of the statuses, with the inclusion of the grace period statuses of the RFC, maxOccurs="unbounded" is correct. The RFC XML schema should be authoritative.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 2/20/25, 12:41 PM, "Thomas Corte (TANGO support)" <thomas.co...@knipp.de <mailto:thomas.co...@knipp.de>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello Gavin, On 20.02.25 18:15, Gavin Brown wrote: > Greetings, > > There is a difference between the XML schema published in the IETF XML > Registry ([1]) and that inlined into RFC 3915. I can't find any indication > that this has previously been noticed. > > Disregarding irrelevant differences in whitespace and comments, the > difference is in the definition of the <rgpStatus> element. In the schema > published by IANA ([1]), it is: > > <element name="rgpStatus" type="rgp:statusType"/> > > In the RFC, it is: > > <element name="rgpStatus" type="rgp:statusType" > maxOccurs="unbounded"/> > > This means that, depending on where the schema was sourced from, different > EPP implementations will disagree on how many <rgpStatus> elements can be > present in EPP commands and responses. > > I have no idea how this happened, but I also have no idea how it should be > fixed. Which version is authoritative? > > * Should the XSD in the IETF registry be updated to match the RFC? > * Should an errata on the RFC be filed? > > I worry that the first option might have an impact on implementations which > automatically pull XSD files from the registry. > > The RFC itself is vague in its intent. Notwithstanding the > maxOccurs="unbounded", throughout the text it says that there can only ever > be a single <rgpStatus> in <info> responses and <update> commands. > > How should this be resolved? Good catch. No idea where the version in the XML registry comes from, but IMO the one from the RFC (allowing multiple RGP status values) should be authoritative one. While you're right that the RFC's text oddly says that there should only be one <rgp:rgpStatus> element in an info response, in our server implementation, this case is possible: <infData xmlns="urn:ietf:params:xml:ns:rgp-1.0"> <rgpStatus s="renewPeriod"/> <rgpStatus s="addPeriod"/> </infData> showing the state of a domain that has been renewed during its Add Grace Period. A rare case for sure, but one that could occur and should be covered by the RFC. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de <mailto:thomas.co...@knipp.de> Germany _______________________________________________ regext mailing list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org <mailto:regext-le...@ietf.org> _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
