Hi, Closing off this thread, I have processed both of the related errata:
https://www.rfc-editor.org/errata_search.php?rfc=3915&rec_status=15&presentation=table Regards, OS, ART AD On Fri, Feb 21, 2025 at 4:47 AM Gavin Brown <gavin.br...@icann.org> wrote: > 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> > wrote: > > > >> -----Original Message----- > >> From: Gavin Brown <gavin.br...@icann.org> > >> Sent: Thursday, February 20, 2025 12:15 PM > >> To: REGEXT Working Group <regext@ietf.org> > >> Cc: Hollenbeck, Scott <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://www.icann.org > > _______________________________________________ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
