Thanks for your comments.
I think you have identified the key issue:
Is an "all-ASCII" email address always a requirement even when SMTPUTF8 is
supported, is there a "transition period"?
See:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-regext-epp-eai-17&url2=draft-ietf-regext-epp-eai-20
Andy,
The redacted extension provides information to the client of what has been
redacted and it's up to the client to determine how to display it. The
implementer needs to leverage the entire specification of the RFC, where in
section 4.2 ""redacted" Member", it fully defines which of the mem
Thanks Andy - I have addressed these issues in draft-ietf-regext-epp-ttl-12
which was just published.
G.
> On 10 Jun 2024, at 13:52, Andrew Newton (andy) wrote:
>
> Hi all,
>
> As document shepherd, the chairs have asked me to confirm on this list that
> all comment received during WGLC, inc
From: Orie Steele
Sent: Monday, June 10, 2024 4:44 PM
To: Hollenbeck, Scott
Cc: regext@ietf.org; regext-cha...@ietf.org
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-eai update
Caution: This email originated from outside the organization. Do not click
links or open attachments unles
Internet-Draft draft-ietf-regext-epp-ttl-12.txt is now available. It is a work
item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live
(TTL) values
Author: Gavin Brown
Name:draft-ietf-regext-
> -Original Message-
> From: Andrew Newton (andy)
> Sent: Tuesday, June 11, 2024 11:12 AM
> To: Hollenbeck, Scott ; regext@ietf.org
> Subject: [EXTERNAL] Re: sacrificial hosts in epp-delete bcp
>
> Caution: This email originated from outside the organization. Do not click
> links
> or ope
On 6/11/24 10:40, Hollenbeck, Scott wrote:
Thanks for the feedback, Andy. More below.
-Original Message-
From: Andrew Newton (andy)
Sent: Monday, June 10, 2024 4:58 AM
To: regext@ietf.org; Hollenbeck, Scott
Subject: [EXTERNAL] sacrificial hosts in epp-delete bcp
Caution: This email
On 6/11/24 07:57, kowa...@denic.de wrote:
Hi,
I think the issue of JSONPath not being easy/possible to interpret in
case of removed paths was brought up on the mailing list and the
conclusion was to key off the "redacted name" rather than base on
JSONPath [1].
This is also what has been c
Hi Pawel,
“Not enough?” – that’s an excellent question. I think 5.1.1 ends up diluting
the normativeness of RFC 9537 (as you earlier mentioned in that thread). It’s
like an implementor saying, “I can’t use JSONPath for my most frequent
(default) removal use case.” and the spec saying, “I know,
Thanks for the feedback, Andy. More below.
> -Original Message-
> From: Andrew Newton (andy)
> Sent: Monday, June 10, 2024 4:58 AM
> To: regext@ietf.org; Hollenbeck, Scott
> Subject: [EXTERNAL] sacrificial hosts in epp-delete bcp
>
> Caution: This email originated from outside the organ
Hi,
The draft-loffredo-regext-epp-over-http (EoH) and draft-yao-regext-epp-quic
(EoQ) drafts were introduced at the IETF-119 REGEXT meeting. Please review the
drafts and provide your feedback on the mailing list or privately.
Thanks,
--
JG
[cid87442*image001.png@01D960C5.C631DA40]
James Go
Hi,
I think the issue of JSONPath not being easy/possible to interpret in
case of removed paths was brought up on the mailing list and the
conclusion was to key off the "redacted name" rather than base on
JSONPath [1].
This is also what has been covered in 5.1.1 with a clear recommendation
We evaluated the possible set of JSON expression languages when starting the
draft. JSONPointer did not have enough features to meet the need. I still
believe that JSONPath is the best expression language to use, but other
expression languages can come on the scene and the extension added expr
Hi Jasdip,
I'm inclined to think that the problem lies in how the JSON content is
structured rather than the language used to select JSON values.
There exist two standard languages to select JSON values, namely
JSONPointer and JSONPath. The former is mostly inapplicable to RDAP as
the values
14 matches
Mail list logo
