Scott,
Changing draft-ietf-regext-rdap-redacted from "Three new RDAP JSON Values
Registry Type field values are used to register
pre-defined redacted name, reason, and expression language values:" to the
below is a good and flexible option.
"This specification defines three new RDAP JSON Val
> -Original Message-
> From: regext On Behalf Of Gould, James
> Sent: Monday, September 11, 2023 11:18 AM
> To: shollenbeck=40verisign@dmarc.ietf.org;
> jgould=40verisign@dmarc.ietf.org; drafts-expert-review-
> comm...@iana.org
> Cc: a...@hxr.us; regext@ietf.org
> Subject: [EXTERNA
Scott,
I like the idea of being able to update the registry to include the additional
Type values, since that would add support for extensibility by the RDAP
extensions. RFC 9083 includes the requirement for the Expert Review process,
which in this case highlights the support for new registry
Jim, RFC 9083 defines the set of type values that can be used to add new
entries to the registry. The draft describes new type values that aren't
included in the existing set, and they can't be added as part of the expert
review process. Either 9083 needs to be updated, or the registry needs to
Scott,
I foresee the need for defining new JSON Values Registry Type values that are
associated with new RDAP extensions. It looks like
draft-ietf-regext-rdap-redacted is the first to do this for the three new types
"redacted name", "redacted reason", and "redacted expression language".
With
A new meeting session request has just been submitted by Antoin Verschuren, a
Chair of the REGEXT Working Group.
-
Working Group Name: Registration Protocols Extensions
Area Name: Applications and Real-Time Area
Session Requester: Antoin
Hi,
Sami Here from D3serve Labs.
Greatly Appreciate everyone's feedback.
>From What I've read it seems that what I've perceived as discrepancies may
be caused by:
- The differences between RFC-7483 and RFC-9083.
- The Huge Difference in response size from different RDAP APIs, due to a
big number of
Hi all,
Please look at this document. It contains a "straw man" implementation of a
syntax for supporting TTLs for different record types.
I do not personally like this syntax but have struggled to find one that both
(a) seems intuitive and (b) can be fully validated using only the XML schema:
