Hi Jasdip,
AFAIU, the name.type value is a shortcut to point to a precise field and
I suppose such pointer should be hardcoded in the client.
When the name.description value is reported, the path value must be used
instead.
However, there are cases where the name.type value is not sufficien
Sorry, forgot "reply to all"
Mario
Messaggio Inoltrato
Oggetto:Re: [regext] using experimental to move items forward
Data: Tue, 18 Jun 2024 10:28:21 +0200
Mittente: Mario Loffredo
A: Andrew Newton (andy)
Hi Andy,
what does it mean "interoperable imp
Hi,
+1 for optimizing the process where possible.
But i wonder why this new process is limited to RDAP extensions only?
What is the distinction between RDAP extensions and other work done in REGEXT
such as EPP extensions?
-
Maarten
> Op 17 jun 2024, om 16:25 heeft Hollenbeck, Scott
> he
Responding to multiple people
On 6/17/24 18:40, George Michaelson wrote:
I have two competing views
1) get rid of time-wasting. If documents something novel in
implementations but there are no implementations, it's not very useful
work. Experimental and Informational are kind of different.
> -Original Message-
> From: Andrew Newton (andy)
> Sent: Tuesday, June 18, 2024 8:10 AM
> To: Mario Loffredo ;
> regext@ietf.org; Maarten Wullink
> ; George Michaelson
>
> Subject: [EXTERNAL] [regext] Re: Fwd: using experimental to move items
> forward
>
> Caution: This email originated
Hi Mario,
That’s a reasonable interpretation of the issues on hand, for both name- and
JSONPath-based redaction in RFC 9537. I think the question would come down to
how far are we willing to evolve the JSONPath portion of RFC 9537 (Scott’s -bis
idea) to guarantee client/server interoperability
> -Original Message-
> From: James Galvin
> Sent: Monday, June 3, 2024 10:56 AM
> To: REGEXT Working Group
> Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-epp-delete-bcp-03
>
> Caution: This email originated from outside the organization. Do not click
> links
> or open attachments
Hi,
In the course of the actual discussion on the clarity of documents we
produce, especially related to implementation maturity of the solutions
I would need to repeat the remark I brought up during the call for
adoption [1].
I think the document, being a BCP, should be very specific about
Pawel, the document already describes known practices, their issues, and those
that are proposed, along with analysis of how they're thought to be better.
What's missing?
Scott
> -Original Message-
> From: kowa...@denic.de
> Sent: Tuesday, June 18, 2024 11:36 AM
> To: regext@ietf.org
>
Hi Scott,
Splitting Section 5 into "Current Practices" and "Proposed experimental
Practices" would offer a lot of more clarity in this respect.
Also abstract is not mentioning proposed practices:
"This document describes best practices to delete domain and host
objects that reduce the risk o
On 6/18/24 08:41, Hollenbeck, Scott wrote:
Because the RDAP extensions seem to be piling up and we seem to have
differing views about their implementations. I think RFC 9537 is a good
example of this... an implementation report would have been very beneficial
as we are now being told the JSONP
Section 5 already identifies the practices as observed or not, but we can add
clarity by splitting it into two sections. We can also update the abstract.
Thanks for the feedback.
Scott
> -Original Message-
> From: kowa...@denic.de
> Sent: Tuesday, June 18, 2024 12:03 PM
> To: Hollenbec
On 6/17/24 08:11, Gould, James wrote:
JG - I agree that this language in the abstract could be better, but the
abstract does not override the content of the entire specification and is
factual. The extension explicitly identifies the redacted RDAP response fields
and JSONPath is the default
Pawel,
Thanks for the feedback and for catching the mismatch between the abstract and
content.
About the suggestion to split section 5, the 00 version of the document split
out practices into "practices to avoid," "best current practices," and
"potential practices" sections. We found that org
14 matches
Mail list logo
