> On 21 Feb 2025, at 12:15, Gould, James <jgo...@verisign.com> wrote:
>
> 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?
Yes, I've written a few, both clients and servers.
I think this could definitely cause issues for EPP clients which expect to only
ever see one <rgpStatus> in responses from servers. I suspect (but do not know
for certain) that it's rare for EPP clients to validate server responses using
the schema, and so any EPP client that does
document.getElementsByTagName("rgpStatus").item(0).getAttribute("s") to obtain
"the" RGP status for the domain may get tripped up if the first element happens
to not have the expected status value.
It would be useful to hear from some EPP client implementers who have
experience with talking to a wide range of servers, as we know that both models
(one vs many) are out there in the wild.
G.
> 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
> <https://urldefense.com/v3/__http://verisigninc.com/__;!!PtGJab4!4-x59mmfF7aD-BEAe7hjqZexWksYzqBIt0zjmSHQIb6I1v6Wp-COuALPDvby599hqfWgz3VoVN65mKUlezm_h9I6$
> [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://urldefense.com/v3/__https://secure-web.cisco.com/18L5oxIE6DhDgSBaDGjLvqPKpeUJ5QRecacvKoYomSjtnqqfs7bEMI9Ro-7V_J_CUqyBzFhbdd4DgEQLcZ6nqM0sGMojfDl8cSXoG4Di-FLky8ucU88iQIYGzqdQkACDwRXCIJZKtzW7nYbWIanEtcMye1akwLpPjYa_rRvw7DEyilUjx0qiri_LTF-YKM4gq9S61lbmQnNFK2zwqEWjitSQECu_cgT0A8YTapJxKO3AeTyV9uLvG0VjtVwRX8ePN9ncGNDT088LZ4cRBoYLXU8feFRv_Ed2LXMn4RKW5uAqu07rio02iedHqXYDiOKZS/https*3A*2F*2Fwww.icann.org__;JSUl!!PtGJab4!4-x59mmfF7aD-BEAe7hjqZexWksYzqBIt0zjmSHQIb6I1v6Wp-COuALPDvby599hqfWgz3VoVN65mKUlewx4Py0J$
> [secure-web[.]cisco[.]com]
> <https://urldefense.com/v3/__https://secure-web.cisco.com/18L5oxIE6DhDgSBaDGjLvqPKpeUJ5QRecacvKoYomSjtnqqfs7bEMI9Ro-7V_J_CUqyBzFhbdd4DgEQLcZ6nqM0sGMojfDl8cSXoG4Di-FLky8ucU88iQIYGzqdQkACDwRXCIJZKtzW7nYbWIanEtcMye1akwLpPjYa_rRvw7DEyilUjx0qiri_LTF-YKM4gq9S61lbmQnNFK2zwqEWjitSQECu_cgT0A8YTapJxKO3AeTyV9uLvG0VjtVwRX8ePN9ncGNDT088LZ4cRBoYLXU8feFRv_Ed2LXMn4RKW5uAqu07rio02iedHqXYDiOKZS/https*3A*2F*2Fwww.icann.org__;JSUl!!PtGJab4!4-x59mmfF7aD-BEAe7hjqZexWksYzqBIt0zjmSHQIb6I1v6Wp-COuALPDvby599hqfWgz3VoVN65mKUlewx4Py0J$
> [secure-web[.]cisco[.]com]>
>
>
> _______________________________________________
> 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>
>
>
--
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
