Hi Jody, Is this a client or a server?
G. > On 23 Jul 2024, at 02:39, Jody Kolker <[email protected]> > wrote: > > Hello all, > > I asked one of our developers at GoDaddy to implement the Redacted RFC with > the changes that were included in the Errata. He was able to implement the > RFC with the proposed redaction as GoDaddy would be using it with redaction > by empty value and redaction by replacement in under two hours. He stated > that GoDaddy's case is pretty simple and the RFC was straightforward to > implement. > > Has anyone else tried to implement the RFC with the additional Errata? > > Thanks, > Jody Kolker > 319-329-9805 (mobile) > > Please contact my direct supervisor Scott Courtney ([email protected]) > with any feedback. > > This email message and any attachments hereto is intended for use only by the > addressee(s) named herein and may contain confidential information. If you > have received this email in error, please immediately notify the sender and > permanently delete the original and any copy of this message and its > attachments. > > -----Original Message----- > From: RFC Errata System <[email protected]> > Sent: Thursday, June 27, 2024 5:26 AM > To: [email protected]; [email protected]; Jody Kolker > <[email protected]>; Roger Carney <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: [regext] [Technical Errata Reported] RFC9537 (8006) > > Caution: This email is from an external sender. Please do not click links or > open attachments unless you recognize the sender and know the content is > safe. Forward suspicious emails to isitbad@. > > > > The following errata report has been submitted for RFC9537, "Redacted Fields > in the Registration Data Access Protocol (RDAP) Response". > > -------------------------------------- > You may review the report below and at: > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8006__;!!PtGJab4!6kcSluu7t6_Chf4zBEr34eQhrGn6r-Mxlgy8PCFNfMjU70rORX1usE8345BLmzXVtqi1CWjDteIi1poigzrYIdpgLjp3rTd0gGH1Wq4e$ > [rfc-editor[.]org] > > -------------------------------------- > Type: Technical > Reported by: James Gould <[email protected]> > > Section: 4.2 > > Original Text > ------------- > The "postPath" member MUST be set when the redacted field does exist in the > redacted response for the Redaction by Empty Value Method (Section 3.2), the > Redaction by Partial Value Method (Section 3.3), and the Redaction by > Replacement Value Method (Section 3.4). > > Corrected Text > -------------- > The "postPath" member MAY be set when the redacted field does exist in the > redacted response for the Redaction by Empty Value Method (Section 3.2), the > Redaction by Partial Value Method (Section 3.3), and the Redaction by > Replacement Value Method (Section 3.4). > > Notes > ----- > The "postPath" member is an OPTIONAL member and this MUST can provide > confusion. The intent of this sentence was to outline which of the path > members ("prePath", "postPath", and "replacementPath") to use when using path > expressions and not to conflict with the OPTIONAL definition. All of the > path expression members are defined as OPTIONAL in the RFC, so this MUST > needs be changed to a MAY to correct the confusion. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it will be > removed shortly by the RFC Production Center.) Please use "Reply All" to > discuss whether it should be verified or rejected. When a decision is > reached, the verifying party will log in to change the status and edit the > report, if necessary. > > -------------------------------------- > RFC9537 (draft-ietf-regext-rdap-redacted-16) > -------------------------------------- > Title : Redacted Fields in the Registration Data Access > Protocol (RDAP) Response > Publication Date : March 2024 > Author(s) : J. Gould, D. Smith, J. Kolker, R. Carney > Category : PROPOSED STANDARD > Source : Registration Protocols Extensions > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
