Gavin, I agree with your proposed items (1. correct the XSD published by IANA; 2. file an errata with corrected text to allow multiple elements.).
Are there any implementations out there that only support a single status element in the info response and update response? That could be the case if the grace period statuses addPeriod, autoRenewPeriod, renewPeriod, and transferPeriod are not supported, since the delete statuses of redemptionPeriod, pendingRestore, and pendingDelete are mutually exclusive. I consider the XSD in the RFC as authoritative for the implementations and the RFC language as an error with the full suite of possible overlapping statuses in the RFC. -- 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/21/25, 5:47 AM, "Gavin Brown" <gavin.br...@icann.org <mailto:gavin.br...@icann.org>> 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. If the schema in the RFC is authoritative, then we have a further issue, in that the narrative text of the RFC seems pretty clear that only one <rgpStatus> element should be present. Section 4.1.2 says: The <rgp:infData> element contains a single <rgp:rgpStatus> element... Section 4.2.5 says: The extension element contains a single child element (<upData>) that itself contains a single child element (<rgpStatus>)... None of the examples show more than a single <rgpStatus> element. So I think two things are needed: 1. correct the XSD published by IANA; 2. file an errata with corrected text to allow multiple elements. Ideally, we'd want to add a constraint on the <rgpStatus> element to disallow duplicates (eg two <rgpStatus s="addPeriod"/> elements) but that is probably beyond what an errata can do. Do we need a -bis?! G. > On 20 Feb 2025, at 17:38, Hollenbeck, Scott <shollenb...@verisign.com > <mailto:shollenb...@verisign.com>> wrote: > >> -----Original Message----- >> From: Gavin Brown <gavin.br...@icann.org <mailto:gavin.br...@icann.org>> >> Sent: Thursday, February 20, 2025 12:15 PM >> To: REGEXT Working Group <regext@ietf.org <mailto:regext@ietf.org>> >> Cc: Hollenbeck, Scott <shollenb...@verisign.com >> <mailto:shollenb...@verisign.com>> >> Subject: [EXTERNAL] RFC 3915 and <rgpStatus> elements >> >> 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. >> >> 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? > > [SAH] I don't know how this happened, either, but the RFC is authoritative. > It's possible that a mistake was made when adding the schema to the registry. > >> * Should the XSD in the IETF registry be updated to match the RFC? >> * Should an errata on the RFC be filed? > > [SAH] My preference would be to update the registry to match the RFC. > >> 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? > > [SAH] I'm interested in hearing other opinions, but as I stated above my > preference is to update the registry. > > Scott -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://secure-web.cisco.com/18L5oxIE6DhDgSBaDGjLvqPKpeUJ5QRecacvKoYomSjtnqqfs7bEMI9Ro-7V_J_CUqyBzFhbdd4DgEQLcZ6nqM0sGMojfDl8cSXoG4Di-FLky8ucU88iQIYGzqdQkACDwRXCIJZKtzW7nYbWIanEtcMye1akwLpPjYa_rRvw7DEyilUjx0qiri_LTF-YKM4gq9S61lbmQnNFK2zwqEWjitSQECu_cgT0A8YTapJxKO3AeTyV9uLvG0VjtVwRX8ePN9ncGNDT088LZ4cRBoYLXU8feFRv_Ed2LXMn4RKW5uAqu07rio02iedHqXYDiOKZS/https%3A%2F%2Fwww.icann.org <https://secure-web.cisco.com/18L5oxIE6DhDgSBaDGjLvqPKpeUJ5QRecacvKoYomSjtnqqfs7bEMI9Ro-7V_J_CUqyBzFhbdd4DgEQLcZ6nqM0sGMojfDl8cSXoG4Di-FLky8ucU88iQIYGzqdQkACDwRXCIJZKtzW7nYbWIanEtcMye1akwLpPjYa_rRvw7DEyilUjx0qiri_LTF-YKM4gq9S61lbmQnNFK2zwqEWjitSQECu_cgT0A8YTapJxKO3AeTyV9uLvG0VjtVwRX8ePN9ncGNDT088LZ4cRBoYLXU8feFRv_Ed2LXMn4RKW5uAqu07rio02iedHqXYDiOKZS/https%3A%2F%2Fwww.icann.org> _______________________________________________ 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
