Hi Mario,
Am 29.11.22 um 07:46 schrieb Mario Loffredo:
Hi Pawel,
Il 28/11/2022 22:02, Pawel Kowalik ha scritto:
Hi Mario,
My comment inline.
Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a
registered reverse
search property and MUST
Hi Jasdip,
thanks for joining the discussion.
I have always been much more in favor of providing self-descriptive REST
APIs (i.e. the HATOAS approach) rather than using a centralized
registry. Therefore, I have always preferred metadata discovery over
registration.
However, I admit that
Hi Tom,
my comments below.
Il 28/11/2022 23:36, Tom Harrison ha scritto:
Hi Mario,
On Mon, Nov 28, 2022 at 07:19:20PM +0100, Mario Loffredo wrote:
Il 27/11/2022 22:49, Tom Harrison ha scritto:
On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
Even now there is no real way to
Hi Pawel,
Il 28/11/2022 22:02, Pawel Kowalik ha scritto:
Hi Mario,
My comment inline.
Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a
registered reverse
search property and MUST NOT match an RDAP property, or any of its
variants,
The following errata report has been verified for RFC9083,
"JSON Responses for the Registration Data Access Protocol (RDAP)".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7094
--
Status:
Hi all,
We've had some positive feedback on this document so far, and would
like to request adoption of it as a working group document.
-Tom
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Hi.
Very interesting discussion. :) Couple of inputs regarding the proposed
discovery and IANA registration of reverse search properties:
In the spirit of what-not-to-do, is it really necessary to evolve reverse
search this way? As long as each registered extension identifier (current and
Hi Mario,
On Mon, Nov 28, 2022 at 07:19:20PM +0100, Mario Loffredo wrote:
> Il 27/11/2022 22:49, Tom Harrison ha scritto:
>> On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
>>> Even now there is no real way to prevent collisions since
>>> extension identifiers and JSON values are
Hi Mario,
My comment inline.
Am 28.11.22 um 21:20 schrieb Mario Loffredo:
"A custom reverse search property MUST NOT collide with a
registered reverse
search property and MUST NOT match an RDAP property, or any of its
variants,
matched by a registered reverse search property."
[PK] not sure
Hi Pawel,
please find my comments below.
Il 28/11/2022 07:54, Pawel Kowalik ha scritto:
Hi,
My comments below.
Am 27.11.22 um 22:49 schrieb Tom Harrison:
[...]
I still think that custom properties are useful for the reasons above.
On the other hand, their possible misuse should be ruled
Hi Tom,
please find my comments below prefixed with ML3.
Il 27/11/2022 22:49, Tom Harrison ha scritto:
Hi Mario,
On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
Il 24/11/2022 13:46, Tom Harrison ha scritto:
This is the part I (still) don't follow, sorry. The fact that the
Does this make sense for use as introductory text to appear in new Section
3.1.2 of what will be -19? Please make suggestions for improvement as you see
fit.
3.1.1 Terminology
3.1.2 Client Considerations
Clients that can accept and process HTTP cookies [RFC6265] as part of
session-oriented
> -Original Message-
> From: regext On Behalf Of Stephane Bortzmeyer
> Sent: Wednesday, November 23, 2022 10:03 AM
> To: regext@ietf.org
> Cc: bortzme...@nic.fr
> Subject: [EXTERNAL] [regext] About conformance to RFC 8521
>
> Caution: This email originated from outside the organization.
Gavin,
Sorry it’s taken me a while to get to this, but I wanted to actually read the
new version of the draft rather than just make comments based on email traffic,
heh.
Regarding the notion of the client providing a , I’d echo Jim’s
comment below regarding a preference to having the values
14 matches
Mail list logo
