[regext] Re: Fwd: New Version Notification for draft-loffredo-regext-rdap-verified-contacts-01.txt

Hi Andy, Verification timestamp is not bound to lifecycle of the entity object. As results the timestamp of verification of the subject may be prior to the creation of the object. Putting this in the events stream may be confusing imho. There will be also potentially more data than just time

[regext] Re: On proposed text alternatives to bare identifiers

Kowalik wrote: - If identifiers are registered with IANA, the risk of naming conflicts is eliminated, making prefixes for identification purposes redundant. - Mandatory prefixes make the protocol less readable and can lead to awkwardly long or abbreviated identifiers, degrading the protocol&#

[regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt

Hi Mario, On 24.07.25 14:24, Mario Loffredo wrote: Hi Pawel, please find my comments inline prefixed with [ML]. Il 22/07/2025 18:23, Pawel Kowalik ha scritto: 1) Some fields in the profile seems duplicated to other fields and I am not convinced we need them at all: components    Name

[regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt

Hi Mario, Thanks for this update. The use of profiles would really make use of JSContact more feasible. After reviewing the document I have few remarks, as indicated in today's IETF 123 WG session: 1) Some fields in the profile seems duplicated to other fields and I am not convinced we nee

[regext] Re: On proposed text alternatives to bare identifiers

Hi Andy et al., First thanks to the editors to incorporate clearly in the draft that there is no consensus yet on this point. I see 3 issues with the current text that I would like to bring up. 1) Suggestive, one sided text in the alternatives I am not fully happy that the text in the option

[regext] Re: JSON syntax for TTL values (was Re: EXTENDED CALL FOR ADOPTION: draft-brown-rdap-ttl-extension)

Hi Gavin, Hi Andy, On 14.07.25 18:03, Andrew (andy) Newton wrote: On 7/14/25 11:38, Gavin Brown wrote: Thanks Jorge! IMHO, the document is pretty much where I wanted to get it, but Maarten did raise this point: i would like to see some changes to the data format if possible, now there ar

[regext] Re: On bare identifiers in Extensions draft

Hi Jasdip, On 18.06.25 19:43, Jasdip Singh wrote: Hi Pawel, Totally agree with being consistent prefixing-wise for query requests and responses in RDAP extensions! But afraid, we might be overlaying this prefixing concept on to the media type space unnecessarily. If another RDAP extension

[regext] Re: On bare identifiers in Extensions draft

We may have more extensions that would want to add media type parameters, so the problem space is the same. (Potential) conflicts occur on the specification level, not in runtime where for all cases (media type parameters, url path segments, JSON names, query parameters) the server will by natu

[regext] Re: On bare identifiers in Extensions draft

Hi Andy, On 02.06.25 16:48, Andrew (andy) Newton wrote: On 6/2/25 03:43, kowa...@denic.de wrote: Hi, [PK] I'm not happy with "technical solution cannot otherwise be defined" as this is a condition likely impossible to fulfil or proof, as there will be always some solution possible. This a

[regext] Re: On bare identifiers in Extensions draft

I would also not put too much value to prefixes. Typically the frameworks require full name anyway to access the object or to map it to a programming language representation. Actually I would be in favour of restoring the text of -04 2.4.5 with an explicit update to RFC9083 allowing the bare i

[regext] Re: recommending I-JSON for RDAP extensions

I don't think extension draft is the right place for this. If we ever think this is an important problem so solve we should update 9083. Kind Regards, Pawel On 21.05.25 21:31, Andrew (andy) Newton wrote: Hi, Sorry for the multiple threads, but I don't want to conflate multiple issues. I

[regext] Re: unicode assignables and RDAP extensions

+1, but I don't think extension draft is enough. It will cover only extension identifiers, object class names, and JSON property names of future extension. Adding it to extension draft is easy and likely not harmful in any way though. Much more interesting would be indeed the string values in

[regext] Re: On bare identifiers in Extensions draft

, Pawel On 12.02.25 18:14, kowa...@denic.de wrote: Hi Scott, On 12.02.25 18:06, Hollenbeck, Scott wrote: *From:* Pawel Kowalik *Sent:* Wednesday, February 12, 2025 11:59 AM *To:* Andrew Newton (andy) *Cc:* regext@ietf.org *Subject:* [EXTERNAL] [regext] Re: I-D Action: draft-ietf-regext-rdap

[regext] Re: A simple test project about using JSContact in RDAP

Hi Mario, Thanks for clarification. From draft-ietf-calext-jscontact-profiles-00 I interpreted that "localized Card replaces one or more top-level properties entirely" means full replacement. Partial replacement would be fine with a small issue of removing items, as then all what localisation

[regext] Re: A simple test project about using JSContact in RDAP

Hi Mario, This is very straightforward. My concern is in the data consistency and redundancy. You have a very nice example, where just postOfficeBox and countryCode are not localised. And even in this example if the localisation would set different countryCode the dataset would be inconsis

[regext] Re: Experimental Extensions (was Re: ONE WEEK REVIEW of FINAL proposed revised charter for REGEXT)

+1 from me as well, WG should be able to work on experimental. On 29.04.25 16:29, Jasdip Singh wrote: +1 IIUC, the proposed change, “IETF consensus”, should help not circumvent IETF’s standardization process for an experimental work that has been adopted by regext, if it comes to that. Jas

[regext] Charter proposal for domain connect (dconn) working group

Hi, After the AD decision not to proceed with the domain connect draft as AD-sponsored the preferred way forward seems to be forming a working group tasked with this work. Orie asked me to propose a charter text and initiate the discussion here. I kept the charter in a very narrow scope, so

[regext] Re: simplifying the extensions rules

Hi Andy, On 31.03.25 16:50, Andrew Newton (andy) wrote: Hi all, At IETF 122, Pawel brought up the lack of time to discuss the simplification of the extension rules as outlined in the email below. From what I can tell, the working group agrees with the simplification of rules on writing RDAP

[regext] Re: simplifying the extensions rules

Hi Andy, On 02.04.25 16:31, Andrew Newton (andy) wrote: [...] In fact "the rules" set in 2.1 of RFC9083 are no rules, but a recommendation (SHOULD) itself. So I argument actually to keep the status quo of RFC9083 as opposed to defining new rules as now the change of -05 proposes. I agree t

[regext] Re: PLEASE RESPOND: INTERIM MEETING PLANNING

one about bare identifiers? Jim/Antoin/Orie, please advise on this matter. Thanks, Jasdip *From:* Pawel Kowalik *Date:* Tuesday, April 1, 2025 at 12:11 PM *To:* Andrew Newton (andy) , regext@ietf.org *Subject:* [regext] Re: simplifying the extensions rules

[regext] Re: simplifying the extensions rules

ng guidance, would it be more productive if we held an interim > meeting before the next IETF to focus on ironing out any disagreements, > especially the one about bare identifiers? > > Jim/Antoin/Orie, please advise on this matter. > > Thanks, > Jasdip > > >

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-05.txt

Hi Andy, On 12.02.25 17:06, Andrew Newton (andy) wrote: Allowing bare identifiers still leave the choice open for extensions which have a potential of generic use. Why does requiring a prefix preclude generic use? Of course technically nothing, because syntactically a prefixed identifier is

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-05.txt

Hi Andrew, On 12.02.25 15:09, Andrew Newton (andy) wrote: On Wed, Feb 12, 2025 at 1:42 AM Pawel Kowalik wrote: [PK] I am typically of an opinion that simple is better than complicated. In this case however I have my concerns that even though new rules would be defined the specifications not

[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-05.txt

Hi Andy, On 05.02.25 21:41, Andrew Newton (andy) wrote: Hi all, We, the author team, have posted a new version of this draft. This reflects 22 closed issues from the tracker, and these are noted in the draft text with an aside. All that said, I think our efforts to do carve-outs based on exist

[regext] Re: CALL FOR ADOPTION: draft-yao-regext-epp-quic and draft-loffredo-regext-epp-over-http

A clear +1 for adoption of DoH. For DoQ I share the opinions expressed in the room in IETF 119 session, that benefits from adding this transport are not clear, so I don't think we should spend cycles on this draft until this is better answered. Adding this new transport on a Standard track wou

[regext] Re: CALL FOR ADOPTION: draft-jasdips-regext-rdap-rpki

Hi, I am not against adopting this document on the merits of it. Especially if there would be folks joining the WG to support its progress. On the other hand I am concerned the WG has still a lot of WIP drafts, which are having moderate traction. We agreed to have "Extension" draft out of th

[regext] Re: Extensions: Referrals handling #56

Hi Andy, On 15.01.25 21:05, Andrew Newton (andy) wrote: On Wed, Jan 15, 2025 at 5:38 AM wrote: Hi Andy, On 14.01.25 17:42, Andrew Newton (andy) wrote: On Fri, Jan 10, 2025 at 12:35 PM wrote: [PK] as indicated above it is not about the extension specifying the referral. Understood, but how

[regext] Re: Extensions: Referrals handling #56

Hi Andy, On 14.01.25 17:42, Andrew Newton (andy) wrote: On Fri, Jan 10, 2025 at 12:35 PM wrote: [PK] as indicated above it is not about the extension specifying the referral. Understood, but how does the current text not allow this? I was guided by the interpretation that the text in 4.2 ap

[regext] Re: Extensions: Current non-compliant extensions #44

Hi Andy, On 14.01.25 17:46, Andrew Newton (andy) wrote: On Fri, Jan 10, 2025 at 1:25 PM wrote: On a side note - forbidding registration will also block the original authors from registering them to make their registration compliant. A bit of paradox. Are you talking past each other? Section

[regext] Re: Extensions: Current non-compliant extensions #44

Hi Andy, On 10.01.25 17:41, Andrew Newton (andy) wrote: This one looks like not normative, for sure not for IANA. This exclusion list should be then included in the IANA considerations which in fact would have the same effect as registering these names as mentioned above. I think putting thes

[regext] Re: Extensions: Non-IETF extensions #42

Hi Andy, On 10.01.25 17:26, Andrew Newton (andy) wrote: 2. what about a general purpose extension which won't get defined by IETF and would like to approach it later? What about them? Is there something so onerous in this requirement that they must break the rules? [PK] Nothing, just lifecyc

[regext] Re: Extensions: Extension identifier case-insensitivity #50

Hi Andrew, On 10.01.25 17:54, Andrew Newton (andy) wrote: On Mon, Jan 6, 2025 at 8:53 AM wrote: [PK] I do not have very hard feelings about changing this MUST NOT but there will be consequences, that MUST NOT will block those extremely marginal but VALID cases (like the one I mentioned abov

[regext] Re: Extensions: Referrals handling #56

Hi Andy, On 10.01.25 18:21, Andrew Newton (andy) wrote: On Wed, Jan 8, 2025 at 10:42 AM wrote: Hi Jasdip, On 03.01.25 22:59, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/56 Section 4.2, paragraph 3 Extensions MUST explicitly define any required b

[regext] Re: Extensions: Clarify search results naming #41

Hi Jasdip, Tom, On 03.01.25 22:41, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/41 >> Section 2.4.4, paragraph 1 >> As described in [RFC9082] and Section 2.3, an extension may define new paths in URLs.  If the extension describes the behavior of an R

[regext] Re: Extensions: Referrals handling #56

Hi Jasdip, On 03.01.25 22:59, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/56 >> Section 4.2, paragraph 3 >> Extensions MUST explicitly define any required behavioral changes to the processing of referrals.  If an extension does not make any provisi

[regext] Re: some feedback on draft-ietf-regext-rdap-versioning

Hi, Inline 2 comments on problem to solve and query params vs. headers. On Mon, Nov 18, 2024 at 1:14 PM Gould, James > wrote: 2. In section 1, the sentence on RDAP conformance values is misleading. I propose: OLD: The RDAP Conformance values are identifiers with

[regext] Re: Extensions: Clarify redirects #55

Hi Jasdip, Tom, Andy, On 03.01.25 22:58, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/55 >> Section 3.1, paragraph 1 >> account for transfers of resources between RIRs.  Section 4.3 of [RFC7480] instructs servers to ignore unknown query parameters. 

[regext] Re: Extensions: Clarify profile extensions #39

Hi Jasdip, Tom, On 03.01.25 22:37, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/39 >> Section 2.1.1, paragraph 1 >> While the RDAP extension mechanism was created to extend RDAP queries and/or responses, extensions can also be used to signal server

[regext] Re: Extensions: Extension identifier case-insensitivity #50

Hi, On 03.01.25 22:52, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/50 >> Section 2.2, paragraph 4 >> [RFC7480] does not explicitly state that extension identifiers are case-sensitive.  This document updates the formulation in [RFC7480] to explicitl

[regext] EPP Extensibility and Extensions Analysis - Registry Survey

Hi, As a preliminary work for analysis of commonly used EPP elements and extensions we launched a TLD registry survey over CENTR and other ccTLD organisations to get some quantifiable insights. Just in case you are not aware of if so far, I forward it here as well, so you may provide your in

[regext] RDAP versioning - on client-server interactions and 2-RTT flow

Hi, Thinking of interactions between the client and server that versioning draft assumes I think we are heading towards 2-RTT model for every request. Step 1: The client makes an HTTP GET request to the /help endpoint of the RDAP server. Step 2: The response is processed to extract rdapConfo

[regext] Review of draft-ietf-regext-rdap-extensions-04

Hi, As extensions draft is the first to get through the WG doors and dependency for others I took it for a more detailed review. Sorry it is quite long. If responding to a particular issue, I would appreciate separate email threads with distinct subject if the issues are not related. This wou

[regext] Re: WGLC: draft-ietf-regext-epp-eai

+1 On 18.11.24 15:17, James Galvin wrote: My apologies folks, I got the subject line wrong. The document in WGLC is: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/22/ Please also take this message as a reminder to indicate your support or any question or concerns you might have

[regext] Re: draft-ietf-regext-rdap-x-media-type-02 Feedback (on rdap-x media type)

Hi, A sub-thread just on this one aspect of media type to be used in rdap-x, or generally content negotiation. On 12.11.24 21:46, Andrew Newton (andy) wrote: responding to both Mario and JGould in line... On Mon, Nov 4, 2024 at 5:50 AM Mario Loffredo wrote: Section 3 "Using The RDAP-X M

[regext] Re: RDAP versioning draft feedback

Hi Jim, To recap on what we discussed in Dublin and to also have input from the working group. Jasdip stated a very valid question. Reading through the draft in more detail I also have a feeling that we are trying to use a sledgehammer to crack a nut. The problem to solve was that RDAP was

[regext] Re: WGLC: draft-ietf-regext-rdap-rir-search-09

Hi Jim and Antoin, It's a bit confusing, as the mail subject relates to draft-ietf-regext-rdap-rir-search and the content to draft-ietf-regext-epp-eai. May you please clarify which document is starting WGLC now? Kind Regards, Pawel On 11.11.24 09:13, James Galvin wrote: The document edito

[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

Hi Tom, On 21.10.24 23:57, Tom Harrison wrote: Hi Pawel, On Mon, Oct 21, 2024 at 09:29:49AM +0200,kowa...@denic.de wrote: [...] In the absence of any text permitting partial implementation, this text requires implementers to implement the whole document ("the functionality specified in this doc

[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

Hi Jasdip, I think "re-using" wouldn't be the right statement. To me it seem that relation search is actually defining a certain extension functionality of an existing search path segment /domains. This is however only implicit, because rfc9082 is actually not defining if a path segment below

[regext] Re: New draft draft-kowalik-regext-domainconnect-00

Hi Marco, Thank you for this remark. It was addressed in https://datatracker.ietf.org/doc/draft-kowalik-domainconnect/00/. Kind Regards, Pawel On 13.09.24 10:38, Marco Davids (IETF IMAP) wrote: Hi Pawel, Op 31-07-2024 om 12:04 schreef Pawel Kowalik: As mentioned there is a renewed draft

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

Hi Andy, On 31.07.24 22:16, Andrew Newton (andy) wrote: Pawel, The issues you have raised about changes necessary for either or both the EPP client and EPP server appear to me to go beyond normative language. Given this type of language  is not in any version of the draft, does this mean you

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

expert in ICANN policies, but maybe it's even needed to change those. Also quite broad tests are likely required if with all those conditions mentioned in 5.1.4.3 are indeed fulfilled in the wild. So I don't feel right to put an equal mark within Best Current Practice document f

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

Comments inline On 31.07.24 17:20, Andrew Newton (andy) wrote: [...] These changes are a result of the shepherd review in checking normative references and normative language (see my other email, which was likely sent when you sent this :) ). Yes, E-mails crossed. I am still not sure how u

[regext] Re: I-D Action: draft-ietf-regext-epp-delete-bcp-07.txt

I am a bit concerned about this draft. We finished WG LC with version -05, then both -06 and -07 appeared without any discussion on the mailing list. It would be ok if there would be just nits, but -06 changed normative language and -07 now reshaped the recommendation section effectively putt

[regext] New draft draft-kowalik-regext-domainconnect-00

Hi, Thank you for a valuable feedback in the session in Vancouver on Domain Connect. As mentioned there is a renewed draft. I would appreciate more feedback from the working group on the content of the document itself, even if not adopted. https://datatracker.ietf.org/doc/draft-kowalik

[regext] Re: [Ext] DSYNC in EPP

Correct, the resellers would want to use it this way and likely they are not reflected in the data model of a registry. DENIC is using such approach for General Contact/Abuse Contact where either registrar default setting applies or a specific one can be assigned for the domain through the pro

[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

Hi, I would not see it that black and white. Scott expressed perfectly yesterday, what I think should be a firm design goal for a RESTful approach, that data representations and protocol interactions should allow for easy and stateless translation layer from/to RFC5730 EPP. I would add that t

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

+1 Kind Regards, Pawel On 24.06.24 15:26, James Galvin wrote: The Chairs have decided to extend this WGLC last call for two weeks, one more week from the date of this message. There has only been on indication of support and two different threads discussing some minor changes. We would lik

[regext] Re: Simple Redaction

Hi Andy, On 21.06.24 16:44, Andrew Newton (andy) wrote: On 6/21/24 09:32, kowa...@denic.de wrote: Hi Andy, Taking into account that this proposal is a result of considerations on rfc9537 I think this draft takes the issue too simplified or easy, just by removing the difficult part of the pr

[regext] Re: Simple Redaction

Hi Andy, Taking into account that this proposal is a result of considerations on rfc9537 I think this draft takes the issue too simplified or easy, just by removing the difficult part of the problem in rfc9537. Actually it dictates allowed methods how redaction is done by the server, practic

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

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

[regext] Re: [Ext] [Technical Errata Reported] RFC9083 (7985)

If Figure 28 is not intended to be a full example, then it should likely use the "..." notation to indicate that better. This notation is used for example in Figure 21 or Figure 25 however it is not consistently used in all examples. Kind regards, Pawel On 14.06.24 15:15, Gavin Brown wrote:

[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

Hi, I think the issue of JSONPath not being easy/possible to interpret in case of removed paths was brought up on the mailing list and the conclusion was to key off the "redacted name" rather than base on JSONPath [1]. This is also what has been covered in 5.1.1 with a clear recommendation

Re: [regext] Re-chartering REGEXT?

+1. Even better if this milestone and discussion would be possible to take place within the current charter or within the re-chartering process. Kind Regards, Pawel On 16.04.24 17:12, Marc Blanchet wrote: It appears to me that we are putting the carriage before the horse in this discussio

Re: [regext] Re-chartering REGEXT?

Hi Mario, On 16.04.24 09:39, Mario Loffredo wrote: However, let me just say that it appears a bit inconsistent to me that we have almost finished to turn RDAP from stateless into stateful and we are now planning to start a discussion about how to make EPP to go opposite !?! You mean the "ses

Re: [regext] Re-chartering REGEXT?

Thank you George. This working group should be the venue for such discussion and if re-chartering is the only clean way forward I'd be also supportive here. Kind Regards, Pawel On 16.04.24 01:14, George Michaelson wrote: I don't think the new protocol is just a new transport *LAYER* but I al

Re: [regext] EPP evolution and the REGEXT charter

issue to proceed let’s discuss what is the best way to address it. I am still of an opinion that this WG is the best group of people with the right expertise to move this topic forward. Kind regards Pawel Kowalik > Am 22.03.2024 um 01:18 schrieb Maarten Wullink > : > >  > RFC5

Re: [regext] EPP Transport Service Discovery

Hi Scott, On 20.03.24 05:56, Hollenbeck, Scott wrote: -Original Message- From: Francisco Obispo Sent: Wednesday, March 20, 2024 12:32 AM To: Hollenbeck, Scott Cc:regext@ietf.org Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery This is a neat idea, Is there a reasoning

Re: [regext] CALL FOR ADOPTION: draft-gould-regext-rdap-versioning draft-newton-regext-rdap-extensions draft-newton-regext-rdap-x-media-type

+1 On 05.02.24 15:37, James Galvin wrote: This is the formal adoption request for the following package of Internet Drafts: Versioning in the Registration Data Access Protocol (RDAP) https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ RDAP Extensions https://datatracker.ietf.

Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp

Hi, I support the adoption. I think this is the right group to work on this issue, however a close sync and thorough review by dnsop shall be assured. One comment/question to the document: my understanding is that it presents a mix of existing and not yet existing or proposed new practices

Re: [regext] ACTION REQUESTED: Re: RDAP-X draft adoption

+1 Am 12.12.23 um 12:14 schrieb Jasdip Singh: +1 Jasdip *From: *Mario Loffredo *Date: *Tuesday, December 12, 2023 at 3:09 AM *To: *"Gould, James" , "gal...@elistx.com" , Jasdip Singh *Cc: *"regext-cha...@ietf.org" , "regext@ietf.org" , Andy Newton *Subject: *Re: [regext] ACTION REQUESTE

Re: [regext] RDAP-X draft adoption

Hi Jasdip, Do you mean by adopting RDAP-X draft the WG shall include the requirements of all the said drafts when it comes to extensions and versions signalling and negotiation, or only keep the current scope and define extension points so that the other drafts can be based on the same method

Re: [regext] CALL FOR ADOPTION: draft-jasdips-regext-rdap-geofeed

I support adoption and I am willing to review. Pawel Am 20.11.23 um 15:36 schrieb Antoin Verschuren: This is a formal adoption request for An RDAP Extension for Geofeed Data: https://datatracker.ietf.org/doc/draft-jasdips-regext-rdap-geofeed/ Please review this draft to see if you thi

Re: [regext] I-D draft-latour-pre-registration

Hi Jack, Skimming through the document I have 3 questions / observations: 1) why you decided to break the flow into 2 commands with create and validate? What shall happen afterwards to the object(s) created in the first step? In this context the approach in draft-ietf-regext-validate to have

Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

Hi James, Likely I missed this part about splitting in the meeting - sorry for that. Can you be more specific? It is the mechanism described in 4.  Transition Considerations? Shall it be only referring to jscontact or contact representation or to any transition of output representations? Her

Re: [regext] [Ext] New Version Notification for draft-ietf-regext-epp-ttl-02.txt

Hi Gavin, Am 20.10.23 um 14:23 schrieb Gavin Brown: Hi Pawel, On 19 Oct 2023, at 06:04, Pawel Kowalik wrote: Hi Gavin, Am 18.10.23 um 13:57 schrieb Gavin Brown: Question on 2.2 element. Why is this element not OPTIONAL? What am I overseeing by thinking it should be optional, as is with

Re: [regext] Call for agenda items IETF 118

I copy on that. It was a topic of wider interest during the last CENTR Tech meeting and it would be good to have a wider IETF community view on this in terms of standards. Kind Regards, Pawel Am 20.10.23 um 10:13 schrieb Maarten Wullink: Andy, Thank you for your kind offer to give up your a

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-01.txt

Hi Andy, Am 25.09.23 um 16:04 schrieb Andrew Newton: I disagree with wrapping name and role in the postal information as those elements are used for non postal reasons and there are definitely non-EPP registries that do not model this the same way. [PK] Makes sense to me to be able to have

Re: [regext] JSON Schema for RDAP RFC-9083

Hi, Some comments below. Am 31.08.23 um 19:56 schrieb Andrew Newton: On Thu, Aug 31, 2023 at 1:05 PM Mario Loffredo wrote: AFAIU, the definition of a standard JSON data description language has been a controversial matter for long. To my knowledge, the only DDL published as RFC that could

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-01.txt

l for entity contact data using basic JSON values, objects, and arrays. The data model defined by this document is purposefully limited to the data in-use by Internet Number Registries and Domain Name Registries and does not attempt to model the full data-set that can be expressed with other

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

Hi, Reading the feedback from John Klensin again, the main problem seems to be that only 1 address does not leave any room for policy choices by all actors in the chain (mainly registries and registrars) whether to support a "backup" all-ASCII address or not. This is a fair point. Now, if we

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt

Hi, > Am 17.07.2023 um 17:32 schrieb Jasdip Singh : > > [JS] This is a fair point, Pawel. Would you suggest considering the latter > method (query parameters) as well, given it may not survive a redirect? Not really. Too much hassle and complexity just to support a de facto non RDAP client. RD

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt

Hi Andrew, Answers inline. Am 12.07.23 um 15:35 schrieb Andrew Newton: Another remark to the media type. RFC7480 specifies the usage of 'application/json', 'application/rdap+json' or both. Why the draft changes the requirement to require only 'application/rdap+json'? Is this change required

Re: [regext] client discovery of server features (was Re: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt)

Hi Andrew, Answers inline. Am 12.07.23 um 16:12 schrieb Andrew Newton: /help is used by humans, if at all. -andy If there are valid use cases, I'd like to hear them. But computing history is full of discovery failures up and down the stack. CORBA. UDDI. DDDS. RDAP OpenID is one of promine

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt

Hi Andy, Thanks for putting down this draft. A method for the client to signal supported or wanted extensions is really needed. A remark to the Section 3: I think all cases should be covered by this section. Currently I'm missing, the case when the server would support more extensions than r

Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt

Hi Andy, Just to be sure - the comments refer to draft-newton-regext-rdap-extensions-00, not to draft-newton-regext-rdap-x-media-type-00, right? I just got confused as the comment are in the thread of the latter. Kind Regards, Pawel Am 26.06.23 um 15:32 schrieb Gould, James: Andy, Thank

Re: [regext] WGLC: draft-ietf-rdap-opened-22

+1 I support the publication of the document. Kind Regards, Pawel Am 26.06.23 um 16:02 schrieb James Galvin: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Federated Authentication

Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11

+1 Am 17.04.23 um 15:27 schrieb Antoin Verschuren: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Redacted Fields in the Registration Data Access Protocol (RDAP) Response https://data

Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20

+1 Am 20.03.23 um 14:40 schrieb James Galvin: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Registration Data Access Protocol (RDAP) Reverse Search https://datatracker.ietf.org/doc/d

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-21.txt

Hi Scott, Feedback inline. Am 02.02.23 um 13:56 schrieb Hollenbeck, Scott: Also the "session" in this case can go beyond the lifespan of the Access Token if token refresh is possible. [SAH] Yes, the concept of the session is directly related to the existence and validity of an Access Token,

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-21.txt

Hi Scott, It looks good, I have few minor points: 1. The new paragraph in Section 3 uses a term "bearer token". I suggest to use "Access Token" as a defined term (same in 6.2). Also the "session" in this case can go beyond the lifespan of the Access Token if token refresh is possible. 2. I

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-20.txt

Hi, Am 26.01.23 um 20:33 schrieb Jasdip Singh: [SAH] Thanks for the feedback, Mario. I still don't think this is a good idea, but if mine is a minority opinion I'll update the text to remove the MUST and include config info so a server can describe the type(s) of clients it supports. Please folk

Re: [regext] RDAP queries based on redacted properties

tocol. Let's wait for a response and then we'll be able to make a definitive proposal about this matter. Meantime, thanks everyone who has joined the discussion thus far. Best, Mario Il 16/01/2023 23:33, Marc Blanchet ha scritto: Le 16 janv. 2023 à 16:18, Pawel Kowalik a é

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-20.txt

Hi Julien, Answer embedded. Am 16.01.23 um 20:33 schrieb Julien Bernard:  - section 4.1 I'm not that familiar with OIDC and that's might be the issue but I don't really understand the need for additionalAuthorizationQueryParams. Is there a way to clarify this or a reference that would help?

Re: [regext] RDAP queries based on redacted properties

Hi Marc, Comment below Am 16.01.23 um 16:49 schrieb Marc Blanchet: Le 11 janv. 2023 à 12:43, Gould, James a écrit : Mario, I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for RDAPs use case. Use of reda

Re: [regext] RDAP queries based on redacted properties

Hi, My comment below. Am 11.01.23 um 19:03 schrieb Marc Blanchet: Le 11 janv. 2023 à 12:43, Gould, James a écrit : Mario, I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for RDAPs use case. Use of redac

Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-19.txt

Hi Scott, Responses below. Am 04.01.23 um 13:58 schrieb Hollenbeck, Scott: - in the Section 3.1.3 the Sequence diagram for session-oriented client should also contain RDAP server <-> OP interactions to correspond to the sequence diagram of token-oriented clients [SAH] What exactly is missing

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

Hi James, Am 22.12.22 um 14:51 schrieb Gould, James: "This document describes an RDAP extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language." This change will be incorpora

Re: [regext] CALL FOR ADOPTION: draft-harrison-regext-rdap-rir-search

I support the adoption. Kind Regards, Pawel Am 19.12.22 um 15:33 schrieb Antoin Verschuren: This is the formal adoption request for RDAP RIR Search: https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-rir-search/ Please review this draft to see if you think it is suitable for

Re: [regext] New version of rdap-reverse-search

Hi, The current draft addresses all the points I've brought up. One of the points was actually the discoverability. The draft describes 4 predefined search properties: fn, handle, email, role. The support for all of them is optional, so the client would not know if the query is supported or no

Re: [regext] draft-ietf-regext-rdap-redacted-10 Posted

Hi James, Please find my comments embedded below. Am 19.12.22 um 14:54 schrieb Gould, James: On 12/19/22, 2:43 AM, "Pawel Kowalik" wrote: Hi James, Thanks for posting the new version incorporating the changes. I reviewed it and have few comments on that: 1.

  1   2   >