I think a -bis would be a good thing. We could add an "ends" attribute so the client knows when the status code will go away.
G. > On 21 Feb 2025, at 12:52, Hollenbeck, Scott <shollenb...@verisign.com> wrote: > >> -----Original Message----- >> From: Gould, James <jgo...@verisign.com> >> Sent: Friday, February 21, 2025 7:16 AM >> To: gavin.br...@icann.org; Hollenbeck, Scott <shollenb...@verisign.com> >> Cc: regext@ietf.org >> Subject: Re: [EXTERNAL] [regext] Re: [Ext] RFC 3915 and <rgpStatus> >> elements >> >> 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. > > [SAH] If we want to go down this path and have the issue documented with a > "hold for update" erratum, I'd be willing to submit a -bis draft to provide > that update. > > Scott -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
