Hi Gavin,
On 21.02.25 14:45, Gavin Brown wrote:
The reason why I discovered this issue is that the new RST v2.0 service ICANN is
building (OT&E now available! Email me to get access)
I requested access through the official channel (https://portal.icann.org) more than two weeks ago,
still wa
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 grac
> -Original Message-
> From: Gould, James
> Sent: Friday, February 21, 2025 7:16 AM
> To: gavin.br...@icann.org; Hollenbeck, Scott
> Cc: regext@ietf.org
> Subject: Re: [EXTERNAL] [regext] Re: [Ext] RFC 3915 and
> elements
>
> Gavin,
>
> I agree with your proposed items (1. correct the XS
If this is an error that should have been caught at the time of
publication, I am happy to mark an errata verified for it.
You can still correct any errata that are verified in a bis document.
On Fri, Feb 21, 2025, 6:52 AM Hollenbeck, Scott wrote:
> > -Original Message-
> > From: Gould
Hello,
On 21.02.25 13:24, Gavin Brown wrote:
I think this could definitely cause issues for EPP clients which expect to only ever
see one 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,
The (ho
Thanks Thomas,
> On 21 Feb 2025, at 13:28, Thomas Corte (TANGO support)
> wrote:
>
> Hello,
>
> On 21.02.25 13:24, Gavin Brown wrote:
>
>> I think this could definitely cause issues for EPP clients which expect to
>> only ever see one in responses from servers. I suspect (but do
>> not kno
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 wrote:
>
>> -Original Message-
>> From: Gould, James
>> Sent: Friday, February 21, 2025 7:16 AM
>> To: gavin.b
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
element should be present.
Section 4.1.2 says:
The element contains a single element...
Section 4.2.5 says:
The extension element contains a singl
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 cas
> On 21 Feb 2025, at 12:15, Gould, James 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
> elem
Dear Antoin Verschuren,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
regext Session 1 (1:00 requested)
Tuesday, 18 March 2025, Session III 1530-1630 Asia/Bangkok
Room Name: Chitlada 3 [Breako
11 matches
Mail list logo
