Re: [regext] Internationalized Email Addresses and EPP

John, The registry can support the receipt of UTF-8 addresses based on the EPP RFCs, but full support comes down to the validation of the email addresses, how the email addresses are stored, and what the email addresses are used for. I would expect an EPP error (2004 "Parameter value range err

Re: [regext] Internationalized Email Addresses and EPP

John, The signal would be handled via support for an EPP extension XML namespace in option 2, an operational practice XML namespace in what I would call 2b, or most likely a new contact XML namespace (contact-1.1) in option 1 for RFC 5733. The XML namespace would be reflected in the EPP greeti

Re: [regext] I-D Action: draft-ietf-regext-unhandled-namespaces-04.txt

The WGLC for draft-ietf-regext-unhandled-namespaces ended on Friday, October 16th. The following are the changes included in draft-ietf-regext-unhandled-namespaces-04: 1. Changed from Best Current Practice (BCP) to Standards Track based on mailing list discussion. – This was agreed to ahe

[regext] FW: I-D Action: draft-ietf-regext-secure-authinfo-transfer-04.txt

The WGLC for draft-ietf-regext-secure-authinfo-transfer ended on Friday, October 16th. The following are the changes included in draft-ietf-regext-secure-authinfo-transfer-04: 1. Converted from xml2rfc v2 to v3. 2. Updated Acknowledgements to match the approach taken by the RFC Editor

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

mes, On Mon, Oct 19, 2020, at 08:31, Gould, James wrote: > Considering a default opt-in puts all currently existing EPP > clients at risk. > > JG - draft-ietf-regext-unhandled-namespaces addresses an > interoperability issue with the server returning ex

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

etf-regext-unhandled-namespaces. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 10/21/20, 5:26 PM, "regext on behalf of Patrick Mevzek" wrote: On Wed, Oct 21, 2020, at

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

ote: On Thu, Oct 22, 2020, at 08:47, Gould, James wrote: > I do need to clarify one > thing, there was no specific changes needed on the client-side to > support draft-ietf-regext-unhandled-namespaces other than ensuring that > the draft-ietf-regext-unhandled-n

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Thomas, Unfortunately returning an error would not enable the client to consume the poll message, which would result in a poison poll message and a large client impact. Use of draft-ietf-regext-unhandled-namespaces within an error response for a poll message would break the processing of poll

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

t-epp-registry-maintenance-03 Thanks for the detailed feedback Jim and apologies for the late reply. Responses are inline. Please let us know if you have any questions. Jody. From: regext On Behalf Of Gould, James Sent: Tuesday, October 6, 2020 2:28 PM To: gal...@elistx.com; regext@ietf.org Sub

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Patrick, Do you mean it's better to fail the login if the client doesn't support all of the possible EPP extensions supported by the poll queue? I view that option as being highly impactful to the clients and it would morph a certain set of services as required by the client at login, which do

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Jim, There is an update planned for draft-ietf-regext-unhandled-namespaces-05 that addresses the concerns that Thomas Corte raised during the WGLC, with the following changes: 1. Based on feedback from Thomas Corte, added a description of the element in RFC 5730 and it being extended t

[regext] FW: I-D Action: draft-ietf-regext-unhandled-namespaces-05.txt

This version of the draft addresses the feedback received from Thomas Corte during the WGLC and addressed two down reference errors identified by idnits. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] [Ext] Benjamin Kaduk's Discuss on draft-ietf-regext-dnrd-objects-mapping-09: (with DISCUSS and COMMENT)

Benjamin, Did the response from Gustavo address your feedback or is there more that needs to be discussed? Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 10/8/20, 5:58 PM, "Gust

Re: [regext] Internationalized Email Addresses and EPP

Klaus, The 3 options presented and discussed at the REGEXT meeting included three extension options, which all include an namespace URI in the greeting and logic services: 1. Placeholder Text and a New Email Element – This matches https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01

Re: [regext] Internationalized Email Addresses and EPP

Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/19/20, 11:56 AM, "Klaus Malorny" wrote: On 19.11.20 16:37, Gould, James wrote: > Klaus, > > [...] > 2. Implicit Replacement Based on Login Services – Inclusion of the > na

Re: [regext] EAI in EPP from a registrar point of view

I agree with Scott's responses, but I need to add some to it, which I embed below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 11/20/20, 12:04 AM, "regext on behalf of Hollenbeck, Sc

Re: [regext] EAI in EPP from a registrar point of view

Klaus, The EAI address issue applies to more than RFC 5733 (RFC 8543 and Email Forwarding Mapping at a minimum) , where even if creating a new version of RFC 5733 made sense, it would not solve the broader issue. The EPP extension option would be straight forward and can be applied across mult

Re: [regext] Mail regarding draft-ietf-regext-secure-authinfo-transfer

Jody, I confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed for draft-ietf-regext-secure-authinfo-transfer. -- JG [cid:image001.png@01D6C18A.C012E640] James Gould Fellow Engineer jgo...@verisign.c

Re: [regext] Internationalized Email Addresses and EPP

-- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/23/20, 1:04 AM, "Alexander Mayrhofer" wrote: Jumping into this discussion quite late, but... On Thu, Nov 19, 2020 at 4:

Re: [regext] draft-ietf-regext-unhandled-namespaces Intellectual Property Disclosure Confirmation Request

I confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed for draft-ietf-regext-unhandled-namespaces. -- JG [cid:image001.png@01D6C260.A0344F40] James Gould Fellow Engineer jgo...@verisign.com 703-948

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

In reviewing draft-ietf-regext-epp-registry-maintenance-05, below is my feedback: 1. Replace “defnition” with “definition” in two places. 2. Section 2.3 Maintenance Elements * I would modify the description of the element. Specifically, change the second sentence to read like “T

Re: [regext] Shepherd's nits on draft-ietf-regext-unhandled-namespaces

David, Thank you for your review feedback. All of the nit updates have been made in draft-ietf-regext-unhandled-namespaces-06. The only change from what you proposed was to use “implementing” instead of “doing” in “the server should consider implementing the following”. The corresponding wor

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

feedback. We will go through it and make the adjustments where needed. Best, Tobias On 1. Dec 2020, at 15:35, Gould, James mailto:jgould=40verisign@dmarc.ietf.org>> wrote: In reviewing draft-ietf-regext-epp-registry-maintenance-05, below is my feedback: 1. Replace “defniti

Re: [regext] Internationalized Email Addresses and EPP

I reviewed the Internationalized Email Addresses and EPP discussion on the list in detail. I want to ensure that the options are clearly covered. The EAI support options discussed thus far include: 1. Do you want the EPP standard to support non-ASCII email addresses? a. Scott Holl

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-rfc7483bis

+1 -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 12/22/20, 7:10 AM, "regext on behalf of Maurizio Martinelli" wrote: +1 Regards, Maurizio >> Il 08/12/2020 20:55, Ant

Re: [regext] EXTENDED 2nd WG LAST CALL: draft-ietf-regext-rfc7482bis

Scott, No issues, add me under the support column. -- JG [cid:image001.png@01D6E4CC.9C6786A0] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com From: regext on behalf of "Hollenbeck, Scott" Date: Thursda

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

Antoin, I was surprised to see draft-ietf-regext-epp-registry-maintenance move to WGLC based on the work that has been progressing on the mailing list, so at this point I can’t support publication of the document. The document editors have addressed my prior feedback. Upon a fresh review, b

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

I completed the action item to see how existing registrar notices map to the elements defined in this section. There was a sidebar with the draft editors that I want to ensure gets on the record. I want to thank the draft editors with being so responsive. Most of the identified gaps have been

Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

Barry, I respond to your feedback embedded below. I saw Martin's reply that I reference for section 3 below. I will publish draft-ietf-regext-unhandled-namespaces-07 once these items are agreed to. Let me know if you agree with the proposed updates below or if you have any additional propos

Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

Barry, Done, draft-ietf-regext-unhandled-namespaces-07 has been posted. Let us know if you have any additional feedback. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 1/26/21,

Re: [regext] AD review of draft-ietf-regext-secure-authinfo-transfer-05

Barry, Thank you for your review and feedback. I respond to your feedback embedded below. I will publish draft-ietf-regext-secure-authinfo-transfer-06 once these items are agreed to. Let me know if you agree with the proposed updates below or if you have any additional proposed changes. Th

Re: [regext] AD review of draft-ietf-regext-secure-authinfo-transfer-05

Barry, Thanks again for reviewing the responses. I provide my responses below on the "verify randomness" item. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 1/28/21, 11:48 AM, "Barry L

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

of this WGLC will follow later this week, but so far I can see no consensus yet, and work still needs to be done. regards, Antoin Op 7 jan. 2021, om 14:39 heeft Gould, James mailto:jgould=40verisign@dmarc.ietf.org>> het volgende geschreven: Antoin, I was surprised to see draft-ietf-

Re: [regext] Opsdir last call review of draft-ietf-regext-unhandled-namespaces-07

Qin, Thank you for your review and feedback. I provide responses to your feedback below. Let me know if you have any additional questions or feedback. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] Genart last call review of draft-ietf-regext-unhandled-namespaces-07

Peter, Thank you for your review and feedback. I provide responses to your feedback embedded below. The updates based on your feedback and other feedback received will be included in draft-ietf-regext-unhandled-namespaces-08. -- JG James Gould Fellow Engineer jgo...@verisign.com 70

Re: [regext] Opsdir last call review of draft-ietf-regext-unhandled-namespaces-07

the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, James: -邮件原件- 发件人: Gould, James [mailto:jgo...@verisign.com] 发送时间: 2021年2月8日 22:42 收件人: Qin Wu ; ops-...@ietf.org 抄送: draft-ietf-regext-unha

Re: [regext] Erik Kline's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)

Erik, In considering your comment: * "does not define new protocol" -> "does not define a new protocol", Perhaps The intent is to indicate that no new EPP protocol elements are defined. How about changing it to "does not define new EPP protocol elements"? This would be included in

Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)

Marray, Thank you for your review and feedback. I provide a response to your comment embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 2/18/21, 1:38 AM, "Murray Kucherawy v

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)

Ben, Thank you for your review and feedback. I provide answers to your feedback below. The referenced updates will be included in the posting of draft-ietf-regext-unhandled-namespaces-08 along with addressing the other feedback. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign

Re: [regext] Secdir last call review of draft-ietf-regext-unhandled-namespaces

Tiru, In re-looking at it, it was intended to reference the set of normative EPP RFC’s used in the draft, which originally included RFC 5730, 5731, 3915, 5910, and 8590. We moved all of the EPP RFCs 3915, 5910, and 8590 from normative references to informational references because they’re onl

Re: [regext] CALL FOR ADOPTION: draft-belyavskiy-epp-eai

Antoin, As a co-author of draft-belyavskiy-epp-eai, I support adoption and I am willing to continue as a co-editor. I anticipate most of the WG discussion to be around the definition of a new form of EPP extension (Functional Extension) and on how to handle the EAI mismatch support cases. I w

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

If the intent is to support a list of description elements, then my recommendation is to update the schema, as previously noted with maxOccurs="unbounded", and update the description of the element with something similar to: Zero or more OPTIONAL free-form descriptions of the maintenance... --

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

hn9m_n0q1Aop-LvX59fsy8JV04r9d-NS_iCDZ5x8vZ_ZXeJt2CO7oDXK27hsU8Mr8S_41nsjRPFrjYDAiFveBRZ3ZkF5Nw_uo2v2SnNYXN7rkMl6JYfcd0O3CGnC0_kwrvWmTkqx6cPzh6l4_7icShqr4GYvhj7rqXvmaccBz2M5PDzZm--ziQiAUKihBIGtyIJkMdPi33ApZBYhIAqUSMx1C5YFQyxN622sUqjir77szIdHyTOIdQrMiPLsb6/https%3A%2F%2Fgithub.com%2Fseitsu%2Fregistry-epp-maintenance%2Fblob%2Fmaster%2Fdraft-ietf-regext-epp-registry-maintenance.txt> Tobias On 6.

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

ance.txt> Tobias On 6. Apr 2021, at 14:21, Gould, James mailto:jgould=40verisign@dmarc.ietf.org>> wrote: If the intent is to support a list of description elements, then my recommendation is to update the schema, as previously noted with maxOccurs="unbounded", and upda

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

PM To: James Gould Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt Thanks, Jim. Please see my comments inline. The updates are done on GitHub for your review. Tobias On 6. Apr 2021, at 18:58, Gould, James m

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

Michael, My feedback in embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/7/21, 2:26 AM, "Michael Bauland" wrote: Hi Jim, On 06.04.2021 21:

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

uch in here. Thoughts? Thanks, Jody Kolker. -Original Message- From: regext On Behalf Of Michael Bauland Sent: Wednesday, April 7, 2021 1:26 AM To: Gould, James Cc: regext@ietf.org Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maint

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

quot;none" would almost be a duplication. And we could save a status to avoid confusion. Tobias > On 7. Apr 2021, at 14:48, Gould, James wrote: > > Jody, > > I replied to Michael previously, but the intent of the "none" impact option i

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

:46 AM, "Tobias Sattler" wrote: Jim, Got it. I guess, I mixed it up with potential(ly). How should we address “none” to avoid that all systems will be listed that aren’t even affected? Tobias > On 7. Apr 2021, at 16:22, Gould, James wrote: > > Tobias,

Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

Tobias, Making it unbounded and a list adds some complexity to the implementation, since it's most likely going to be a single element. I understood the reasoning behind it and therefore I'm fine with it. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemo

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-epp-registry-maintenance

Antoin, All of my feedback has been addressed in draft-ietf-regext-epp-registry-maintenance and I support it moving forward. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 3/29/21, 9:2

Re: [regext] Lars Eggert's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Lars, Thank you for your review and feedback. Embedded I include responses to your comments. The updates made to the draft will be included in the publishing of draft-ietf-regext-secure-authinfo-transfer-07 after all feedback has been received. Thanks, -- JG James Gould Fellow Enginee

Re: [regext] Robert Wilton's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Robert, Thank you for your review and feedback. I provide responses to your feedback embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/19/21, 7:57 AM, "Robert Wilton via

Re: [regext] Martin Duke's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Martin, Thank you for the review and feedback. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/9/21, 8:17 PM, "Martin Duke via Datatracker" wrote: Martin Duke has entered the fol

Re: [regext] Francesca Palombini's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Francesca, Thanks for the review and feedback. Good catch on the copy/paste issue in section 5.2. The first paragraph will be removed, since the second paragraph contains everything of the first with additional content. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com

Re: [regext] Roman Danyliw's No Objection on draft-ietf-regext-secure-authinfo-transfer-06: (with COMMENT)

Roman, Thank you for your review and feedback. My responses are embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 4/20/21, 9:01 PM, "Roman Danyliw via Datatracker" wrote:

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

Benjamin, Thank you for your review and feedback. I provides responses to your feedback embedded below. Updates will be made to draft-ietf-regext-secure-authinfo-transfer-07 that will include changes from all of the feedback. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

Also inline. On Mon, Apr 26, 2021 at 09:08:29PM +0000, Gould, James wrote: > Benjamin, > > Thank you for your review and feedback. I provides responses to your feedback embedded below. Updates will be made to draft-ietf-regext-secure-authinfo-transfer-07 that will

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-secure-authinfo-transfer-06: (with DISCUSS and COMMENT)

"Benjamin Kaduk" wrote: Hi James, My apologies for the again-delayed response. Continuing inline and skipping points that are resolved... On Mon, May 10, 2021 at 09:00:27PM +, Gould, James wrote: > Benjamin, > > I provide respon

[regext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

The "Redacted Fields in the Registration Data Access Protocol (RDAP) Response" draft-gould-regext-rdap-redacted has been published. The goal of the draft is to describe an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.

Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

ple languages. Really would like this document to move forward. As RDAP client implementor, I would like to implement it. If some servers are already implementing it, please contact me directly so we can do some interop testing. Marc. > Le 12 juill. 2021 à 07:02, Gould, James

Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-04.txt

In reviewing the changes made to draft-ietf-regext-simple-registration-reporting-04, I have the following feedback: 1. The sentence "Each report definition MUST use only the data elements defined in the data element aforementioned data element registry, including all future reports." could be

Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

gninc.com/> From: Marc Blanchet Date: Monday, July 12, 2021 at 7:41 AM To: James Gould Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt Le 12 juill. 2021 à 07:26, Gould, James mailto:jgo...@verisign.com>

Re: [regext] New Version Notification for draft-gould-regext-rdap-redacted-00.txt

io Loffredo" wrote: Hi all, Il 12/07/2021 13:26, Gould, James ha scritto: > Marc, > > Thank you for the quick review and feedback. Below are responses to your early comments: > > - would be good to include specific text about jscontact, so when

Re: [regext] [Ext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

in: The Redaction by Empty Value Method SHOULD be used only when redacting JSON response fields that use the position in an array to signal the redacted field (e.g., jCard [RFC7095] arrays). Thank you, Gustavo On 7/12/21, 04:03, "regext on behalf of Gould, James" wrote:

Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

for draft-gould-regext-rdap-redacted-00.txt Data: Wed, 14 Jul 2021 14:06:47 +0000 Mittente: Gould, James <mailto:jgould=40verisign@dmarc.ietf.org> A: mario.loffr...@iit.cnr.it<mailto:mario.loffr...@iit.cnr.it> <mailto:mario.loffr...@iit.cnr.it>, marc.blan

Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

, 2021 at 3:56 AM To: James Gould Cc: "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-gould-regext-rdap-redacted-00.txt Hi James, please find my replies below. Il 15/07/2021 19:40, Gould, James ha scritto: Mario, My responses are embedde

[regext] draft-ietf-regext-epp-eai Predefined Placeholder Email Value

There is one TBD item that exists in section 5.3.2 of draft-ietf-regext-epp-eai related the “predefined placeholder email” that is used by the EAI supporting server and EAI supporting client where the opposite party doesn't support EAI. In both cases a valid email value needs to be provided to

Re: [regext] draft-ietf-regext-epp-eai Predefined Placeholder Email Value

is, that you can use example.com/org/net for that purpose, too, as they are reserved TLDs. empty.as112.arpa has no MX record, too, therefore, I don‘t get the advantage of it. Best, Tobias Am 22.07.2021 um 18:06 schrieb Gould, James : There is one TBD item that exists in section 5.3.2 of draft

Re: [regext] [Ext] FW: New Version Notification for draft-gould-regext-rdap-redacted-00.txt

ethods described in section 5 are insufficient. Regards, Gustavo On 7/14/21, 10:51, "Gould, James" wrote: Gustavo, Thank you for your quick review and feedback. I provide my replies to your feedback embedded below. -- JG

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

Marco, The issue is associated with a transition state when one side of the connection (registrar or registry) supports EAI while the other does not, the email element is required by the protocol, and the only value available is an EAI address. The EAI-supporting side can’t pass the EAI valu

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

rt EAI and Server not it can only be prohibited. Regards Marco Am 02.08.21 um 15:50 schrieb Gould, James: > Marco, > > > > The issue is associated with a transition state when one side of the > connection (registrar or registry)

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

8/2/21, 11:42 AM, "regext on behalf of Thomas Corte (TANGO support)" wrote: Hello, On 8/2/21 15:50, Gould, James wrote: > 2. EPP Contact Response > (https://secure-web.ci

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

On Mon, Aug 2, 2021, at 08:50, Gould, James wrote: > I believe the use of a predefined placeholder value is the best > approach to handle this transition corner case in the protocol, but I > would like to hear viable alternates from the working group to > incorporat

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/2/21, 2:32 PM, "regext on behalf of Patrick Mevzek" wrote: On Mon, Aug 2, 2021, at 13:22, Gould, James wrote: > You can reply to my reply to > Thomas Corte with your though

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

NGO support)" wrote: Hello, On 8/2/21 20:08, Gould, James wrote: > Thomas, > > For use case #2 (info response of EAI address with non-EAI supporting > client), your preference is to return a failure. Is 2308 “data > management policy violati

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

Aug 2021, at 21:08, Gould, James wrote: > > Thomas, > > For use case #2 (info response of EAI address with non-EAI supporting client), your preference is to return a failure. Is 2308 “data management policy violation” the best error code in your opinion? Do

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

emont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/4/21, 4:18 PM, "Taras Heichenko" wrote: Hi James, all. > On 4 Aug 2021, at 15:38, Gould, James wrote: > > Thank you for your perspective for use case #2 (info response of EAI address

Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

Gustavo, Good point, I agree that returning the 2308 “Data management policy violation” error response is the best option for the use case when the client doesn’t support EAI per the login services and the optional e-email response value is an EAI. To map this up to the EPP RFCs with an email

Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

Scott, Agreed, the title is better as “Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)”. The EPP RFCs have included “Extensible Provisioning Protocol (EPP)” in the title, so it would be most consistent to include the long form. -- JG [cid:image001.png@

Re: [regext] pass on the lower fee

Agreed, for this use case I would go with a renew change poll message with the registry fee extension, such as: S: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2021-08-17T22:00:00.0Z S: Auto renew dis

Re: [regext] pass on the lower fee

Martin, If you do return the extension in a poll response it should be included in the greeting services. My recommendation is to fully implement the registry fee extension along with this so not to cause client confusion. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-

Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-01.txt

draft-ietf-regext-rdap-redacted-01 was posted that includes updates associated with feedback from Gustavo Lozano, Marc Blanchet, and Mario Loffredo. This version adds the use of the JSON Values Registry for the registration of redacted name and reason values. One item that was discussed with t

Re: [regext] [check] always prohibited when avail="1" ?

I would be more concerned about injecting domain names into the check response that were not queried for in the command than the inclusion of the optional reason element to explain why the domain name was added. I looked at the approach taken with a similar extension, which is the Related Domai

[regext] FW: I-D Action: draft-ietf-regext-rdap-redacted-02.txt

Support for RDAP search responses was added in draft-ietf-regext-rdap-redacted-02. JSONPath (draft-ietf-jsonpath-base ) does not support an up operator to use relative JSONPaths in the "path" member, so draft-ietf-regext-rdap-redacted-02 specifies the use of an absolute path (e.g., "$.domainSe

Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt

I view the jscontact is a valid use case for a standards track RDAP extension. We have many similar use cases for standards track extensions in EPP, where the RFCs couldn't envision a feature or an approach that comes up later. The jscontact draft needs to be defined as an RDAP extension that

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

Scott, Thanks for the review and feedback. I provide responses to your feedback embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 12/6/21, 9:18 AM, "regext on behalf of Hol

Re: [regext] Redacted implemented server side?

Mario and Marc, It's great to see plans to implement both a production client and server. Receiving implementation feedback would be very valuable. Once you have something in place, please let us know and we can add an Implementation Status section to the draft to include both the client and

Re: [regext] Feedback about rdap-redacted doc

Mario, I believe that your second option is the simpler one. I agree that we should add an entry in section 5 "JSONPath Considerations" to address it. How about the following entry? When there are multiple entities with the same role, include "redacted" members for each entity using the enti

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

Mario, Thank you for sharing the draft. We implemented EPP/HTTPS in parallel with EPP/TLS a while back for many years. In the end, there were very few registrars that chose to use EPP/HTTPS, so it was shutdown. I’m not sure at this point whether there is hunger from the registrars to impleme

Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-06.txt

Hi, I did a detailed review of draft-ietf-regext-simple-registration-reporting-06 and below is my feedback: 1. Introduction * I’m not sure whether there have been “a number of best practice reports that have evolved”, but I do agree that there have been “a number of best practice

[regext] draft-ietf-regext-rdap-redacted Support for Redaction by Replacement Value Method

There was discussion in the ICANN RDAP working group associated with the requirement for the “Registrar MUST publish an email address or a link to a web form for the email value to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address”, based o

Re: [regext] Comments to the feedback about epp-over-http

Mario, For #4 “Cookie vs. HTTP Connection”, you asked the question “can you further clarify why we should opt for establishing the cookie at setup of the connection and how should it be possible? For example, what kind of request should be used to start the HTTP connection?”. I implemented plu

Re: [regext] Comments to the feedback about epp-over-http

James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http Hi James, thanks for ypur quick reply. Please find my comments below. Il 25/03/2022 16:45, Gould, James ha scritto: Mario, For #4 “Cookie vs. HTTP Connection”, you asked the q

Re: [regext] Comments to the feedback about epp-over-http

AM To: James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http Hi James, Il 29/03/2022 13:41, Gould, James ha scritto: Mario, My feedback is embedded below. -- JG [cid:image002.png@01D84363.253C6D10] James Gould Fellow Engineer jgo

Re: [regext] Comments to the feedback about epp-over-http

AM To: James Gould , "regext@ietf.org" Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http Hi James, my comments are embedded below. Il 29/03/2022 17:50, Gould, James ha scritto: Mario, My responses are embedded below. -- JG [cid:image002.png@01D8441C.

Re: [regext] Document Shepard Review of draft-ietf-regext-epp-eai-07

Jody, Thank you for doing the document shepherd review of draft-ietf-regext-epp-eai. I include my responses to your feedback embedded below. -- JG [cid:image001.png@01D845E4.58A55580] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.

Re: [regext] Document Shepard Review of draft-ietf-regext-epp-eai-07

Jody, I am not aware of any IPR that requires disclosure under the provisions of BCP 78 and BCP 79 for draft-ietf-regext-epp-eai. -- JG [cid:image001.png@01D84F5C.A6C00FE0] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com

Re: [regext] in

+1 on the use 2103/"Unimplemented extension". This is a broader topic with the passing invalid or conflicting extensions (e.g., restore request extension of update along with the sync extension). -- JG James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Re

Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

I did a review of the latest version of the draft (draft-ietf-regext-rdap-reverse-search-10), and below is my feedback: 1. Abstract * It states, “This document describes RDAP query extensions”. Shouldn’t it be “this document describes an RDAP query extension” in the singular form?

<    2   3   4   5   6   7   8   >