Gavin,
I agree that a -bis draft would be a good thing. Adding an "ends" or similar
attribute to the grace period statuses would be useful. This would be
applicable for the grace period statuses (e.g., addPeriod, renewPeriod,
autoRenewPeriod, transferPeriod) to inform the client when the grace period
expires. This would also be applicable to the delete RGP statuses (e.g.,
redemptionPeriod, pendingRestore, and pendingDelete), where they progress
through a state machine and the client can be informed of when the status will
end, such as redemptionPeriod moving to pendingDelete or pendingDelete
resulting in a purge. The "ends" attribute would help with the pendingRestore
status also, since the restore is a two-step process and the restore request
will expire if the restore report is not received within a timeframe determined
by server policy. We may want to reconsider the two-step restore process,
since it's unclear why it's currently a two-step process.
I looked at the Versign EPP SDK and I noticed it supports a list of RGP
statuses in the info response but a single RGP status in the update (restore)
response. Where the list of RGP statuses apply is for the grace period
statuses, since they can overlap, which only applies prior to the delete
command. The delete statuses (e.g., redemptionPeriod, pendingRestore, and
pendingDelete) are mutually exclusive and since they are returned after the
delete command there are no applicable grace period statuses to return. So, in
the case of the update (restore) response, only a single RGP status applies.
The Verisign registries return a list of RGP statuses in the info response
along with the end date using the status text node, so adding an "ends"
attribute would be better. The update (restore) response only returns a single
RGP status from the mutually exclusive delete statuses (e.g., redemptionPeriod,
pendingRestore, and pendingDelete), since as noted above the grace period
statuses don't apply post the delete command.
The following is an example of the redemptionPeriod status returned in the info
response after a successful delete:
<rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
<rgp:rgpStatus
s="redemptionPeriod">endDate=2025-03-23T15:32:32Z</rgp:rgpStatus>
</rgp:infData>
Thanks,
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 2/21/25, 8:45 AM, "Gavin Brown" <[email protected]
<mailto:[email protected]>> 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.
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 <[email protected]
> <mailto:[email protected]>> wrote:
>
>> -----Original Message-----
>> From: Gould, James <[email protected] <mailto:[email protected]>>
>> Sent: Friday, February 21, 2025 7:16 AM
>> To: [email protected] <mailto:[email protected]>; Hollenbeck, Scott
>> <[email protected] <mailto:[email protected]>>
>> Cc: [email protected] <mailto:[email protected]>
>> 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://secure-web.cisco.com/1Eo04PjHF45dZfw-RpD8u2zsvxoI9ztjenYMJk8KNTTei4dEq5Z9CGa23vgm1zSFi1s1gIWY-nVTyhauSKlSOUqOZ5bFqCmmtv1opFnf0d-jpOdB1NWqMe4GewGkJx2pUmVoStLiYzBQFJIA6yN1-EbUZ9Hrky1oANvK0cupWnnb3WguWLB9GCHyo9WnPwcX2vRh4kSKnVGz6c4RST4o-ca7QCPGG3YR3y_bAq-fpsK5LNpHJIH3ZXun7XTzQLeH0fODLt8pwUxnVPCdabAdCcxHnESSstWMHhPAMb1fgoIo/https%3A%2F%2Fwww.icann.org
<https://secure-web.cisco.com/1Eo04PjHF45dZfw-RpD8u2zsvxoI9ztjenYMJk8KNTTei4dEq5Z9CGa23vgm1zSFi1s1gIWY-nVTyhauSKlSOUqOZ5bFqCmmtv1opFnf0d-jpOdB1NWqMe4GewGkJx2pUmVoStLiYzBQFJIA6yN1-EbUZ9Hrky1oANvK0cupWnnb3WguWLB9GCHyo9WnPwcX2vRh4kSKnVGz6c4RST4o-ca7QCPGG3YR3y_bAq-fpsK5LNpHJIH3ZXun7XTzQLeH0fODLt8pwUxnVPCdabAdCcxHnESSstWMHhPAMb1fgoIo/https%3A%2F%2Fwww.icann.org>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
