Hi Cynthia,
Thank you for troubleshooting that font-size issue. :) We had also noticed it
but still needed to figure out. We’ll try rectifying this, along with the typo,
in the next version.
Regards,
Jasdip
From: Cynthia Revström
Date: Sunday, July 27, 2025 at 11:54 AM
To: regext@ietf.org
Su
Hi Mario, Pawel,
Please see my comments below.
Thanks,
Jasdip
From: Pawel Kowalik
Date: Thursday, July 24, 2025 at 6:09 PM
To: Mario Loffredo , Pawel Kowalik
, regext@ietf.org
Subject: [regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt
1) Some fields in the profile seems
Key Infrastructure (RPKI) Registration Data
Authors: Jasdip Singh
Andy Newton
Name:draft-ietf-regext-rdap-rpki-02.txt
Pages: 50
Dates: 2025-07-20
Abstract:
The Resource Public Key Infrastructure (RPKI) is used to secure
inter-domain routing on the internet. This docu
Hi.
Sorry, a bit late but +1 for adopting this draft.
Thanks,
Jasdip
From: Jorge Cano
Date: Monday, June 23, 2025 at 11:31 AM
To: regext
Subject: [regext] CALL FOR ADOPTION: draft-brown-rdap-ttl-extension
Hi all,
This is a formal adoption request for RDAP Extension for DNS Time-To-Live:
Forgot to include regext. :)
Jasdip
From: Jasdip Singh
Date: Monday, June 30, 2025 at 10:48 AM
To: Mario Loffredo
Subject: Re: [regext] Re: RDAP JSContact -21 feedback
Hi Mario,
From: Mario Loffredo
Date: Monday, June 30, 2025 at 3:46 AM
To: Jasdip Singh
Subject: Re: [regext] Re: RDAP
Hi Mario,
Sorry for my late reply.
Please find my comments below.
Thanks,
Jasdip
From: Mario Loffredo
Date: Thursday, April 24, 2025 at 8:43 AM
To: Jasdip Singh , regext@ietf.org
Subject: [regext] Re: RDAP JSContact -21 feedback
…
6.3. RDAP Reverse Search Mapping Registry
“Searchable
From: Gould, James
Date: Tuesday, June 24, 2025 at 1:09 PM
To: Jasdip Singh , kowa...@denic.de ,
a...@hxr.us , Hollenbeck, Scott ,
maarten.wull...@sidn.nl
Cc: regext@ietf.org
Subject: Re: Re: [regext] Re: On bare identifiers in Extensions draft
Jasdip,
I believe the guidance should be to
type. ;) The closest prefixing example for regext purposes has been
“rdap-up”, etc for the RIR search, whereas “geofeed” was allowed for the RDAP
Geofeed from specificity angle.
Thanks,
Jasdip
From: Pawel Kowalik
Date: Tuesday, June 24, 2025 at 1:42 AM
To: Jasdip Singh , Gould, James ,
a
are right this would be a
new extension point in the RDAP Extensions draft.
Thanks,
Jasdip
From: Gould, James
Date: Wednesday, June 18, 2025 at 2:04 PM
To: Jasdip Singh , kowa...@denic.de ,
a...@hxr.us , Hollenbeck, Scott ,
maarten.wull...@sidn.nl
Cc: regext@ietf.org
Subject: Re: [regext] Re
WG before doing
such prefixing of parameters for media types that get created as part of RDAP
extensions.
Thanks,
Jasdip
[1]
https://www.ietf.org/archive/id/draft-ietf-mediaman-6838bis-05.html#name-parameters
From: Pawel Kowalik
Date: Wednesday, June 18, 2025 at 4:42 AM
To: Jasdip Singh
ce, no need for prefixing a media type’s
parameters.
Jasdip
[1] https://www.iana.org/assignments/media-types/media-types.xhtml
From: Gould, James
Date: Monday, June 16, 2025 at 2:39 PM
To: Jasdip Singh , a...@hxr.us ,
kowa...@denic.de , Hollenbeck, Scott
, maarten.wull...@sidn.nl
Cc: regext@ie
Hi James,
The string literal “rdapExtensions1” is intended as this ‘profile’ extension’s
identifier, per the Extension Identifier section [1].
Not sure if we need such prefixing to avoid parameter collision for media
types, like “application/rdap+json”, that the IETF produces. AFAIK, this is no
Hi,
As I gather from this thread, we all seem to agree that a bare identifier could
co-exist with a prefix identifier for an extension as a namespace-collision
prevention approach in RDAP. Albeit, for a qualified scenario when only a
single JSON member, query path, query parameter and/or object
Internet-Draft draft-ietf-regext-rdap-rpki-01.txt is now available. It is a
work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
Title: Registration Data Access Protocol (RDAP) Extension for Resource
Public Key Infrastructure (RPKI) Registration Data
Authors: Jasdip Singh
From: Hollenbeck, Scott
Date: Wednesday, May 21, 2025 at 3:24 PM
To: a...@hxr.us , regext@ietf.org
Subject: [regext] Re: unicode assignables and RDAP extensions
> -Original Message-
> From: Andrew (andy) Newton
> Sent: Wednesday, May 21, 2025 3:21 PM
> To: regext@ietf.org
> Subject: [E
Thanks, Antoin.
Jasdip
From: Antoin Verschuren
Date: Monday, May 19, 2025 at 10:10 AM
To: Jasdip Singh
Cc: REGEXT WG Chairs , REGEXT Working Group
Subject: Re: [regext] RDAP Extensions draft shepherd
Done as well,
Jim and Antoin
Op 18 mei 2025, om 15:19 heeft Jasdip Singh
mailto:jasd
Hi Jim, Antoin,
Pawel Kowalik has agreed to be the document shepherd for the “RDAP Extensions”
draft [1]. Please add him so to this draft.
Thanks, Pawel!
Jasdip
[1] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/
___
regext maili
Hi Jim, Antoin,
Mario Loffredo has graciously agreed to be the document shepherd for the
“Extensions Parameter for the RDAP Media Type” draft [1]. Please add him so to
this draft.
Thank you, Mario. :)
Regards,
Jasdip
[1] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/
_
Surely, Rifaat. But will rephrase as:
“The geofeed file MUST be referenced with an HTTPS URL, per Section 6 of
[RFC9632].”
Since section 6 from RFC 9632 contains a more assertive statement: “The geofeed
files MUST be published via and fetched using HTTPS [RFC9110].”
Hope that’s ok.
Jasdip
Fr
Hi Alexey,
Thank you for your review. Please see our comments below.
Regards,
Jasdip & Tom
From: Alexey Melnikov
Date: Tuesday, May 6, 2025 at 9:44 AM
To: drafts-expert-review-comm...@iana.org
Cc: dar...@tavis.ca , regext@ietf.org
Subject: [regext] Re: [IANA #1414868] expert review for
dra
Hi Mario,
That’s good to know. Thanks for the update.
Jasdip
From: Mario Loffredo
Date: Wednesday, April 30, 2025 at 3:27 AM
To: Jasdip Singh , regext@ietf.org
Subject: [regext] Fwd: Re: A simple test project about using JSContact in RDAP
Hi Jasdip,
just removed SuperBuilder.
The remaining
Hi Mario,
I also just reviewed it. :) Looks simple enough using Lombok and @JsonProperty.
One concern could be the experimental status of Lombok’s @SuperBuilder but
looks like it’s here to stay. Thanks for sharing.
Jasdip
From: Mario Loffredo
Date: Tuesday, April 29, 2025 at 9:46 AM
To: regex
+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.
Jasdip
From: Andrew (andy) Newton
Date: Tuesday, April 29, 2025 at 9:22 AM
To: James Galvin , REGEXT Workin
Hi Dale,
From: Dale R. Worley
Date: Friday, April 18, 2025 at 10:41 AM
To: Jasdip Singh
Cc: gen-...@ietf.org ,
draft-ietf-regext-rdap-geofeed@ietf.org
, last-c...@ietf.org
, regext@ietf.org
Subject: Re: Genart last call review of draft-ietf-regext-rdap-geofeed-09
Jasdip Singh writes
Hi Mario,
I reviewed the latest RDAP JSContact draft. :) Please find below my feedback:
6.3. RDAP Reverse Search Mapping Registry
“Searchable Resource Type: domains, nameservers, entities”
Since the RDAP RIR Search draft also includes reverse search [1], should we
include “ips” and “autnums”
Hi,
Since we are in the midst of discussing the RDAP Extensions draft [1], should
that draft also consider the sunsetting of an RDAP extension? AFAIK, no RDAP
extension has been completely sunset at the IANA RDAP Extensions registry [2]
level but that could change in the future.
Thanks,
Jasdip
Hi Dale,
Thank you for your review of this draft. Please find below our comments.
Also, please see [1] for the diffs in the updated draft.
Thanks,
Jasdip & Tom
[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-10
From: Dale Worley via Datatracker
Date: Friday, March
Hi Mark,
Thank you for your review of this draft. Please find below our comments.
Also, please see [1] for the diffs in the updated draft.
Thanks,
Jasdip & Tom
[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-10
From: Mark Nottingham
Date: Saturday, March 15, 2025
Hi Dhruv,
Thank you for your review of this draft. Please find below our comments.
Also, please see [1] for the diffs in the updated draft.
Thanks,
Jasdip & Tom
[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-10
From: Dhruv Dhody via Datatracker
Date: Tuesday, Ap
Hi Rifaat,
Thank you for your review of this draft. Please find below our comments.
Also, please see [1] for the diffs in the updated draft.
Thanks,
Jasdip & Tom
[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-10
From: Rifaat Shekh-Yusef via Datatracker
Date: Frid
Hi all,
Since this Extensions draft would be a useful contribution for clarifying the
RDAP extensibility, and that there are other drafts waiting on it for a more
definitive naming guidance, would it be more productive if we held an interim
meeting before the next IETF to focus on ironing out a
+1
Looks like an hour should suffice.
Thanks,
Jasdip
From: Gould, James
Date: Wednesday, April 2, 2025 at 10:29 AM
To: mario.loffredo=40iit.cnr...@dmarc.ietf.org
,
shollenbeck=40verisign@dmarc.ietf.org
, gal...@elistx.com
, Jasdip Singh
Cc: a...@hxr.us , regext@ietf.org
Subject: Re
Hi,
Andy sent a note [1] to the media-types mailing list for guidance on whether we
need a new media type “application/rdap-x+json” with the “extensions” parameter
for content negotiation in RDAP (option 1), or if adding the “extensions”
parameter to the existing “application/rdap+json” media t
Hi David,
We, the authors, are aware of this feedback and would be addressing it soon.
Thanks,
Jasdip
From: David Dong via RT
Date: Thursday, February 27, 2025 at 1:55 PM
To:
Cc: regext@ietf.org ,
draft-ietf-regext-rdap-rir-search@ietf.org
Subject: [IANA #1413017] expert review for draft
Hi Antoin, Jim,
Scott Hollenbeck has graciously agreed to be the document shepherd for this
draft. :)
Jasdip
From: Jasdip Singh
Date: Tuesday, February 4, 2025 at 12:51 PM
To: Antoin Verschuren , regext
Subject: [regext] Re: CALL FOR ADOPTION: draft-jasdips-regext-rdap-rpki
Hi Antoin, Jim
Hi Antoin, Jim,
Version 00 of this draft has now been submitted. Good idea to have the RPKI
experts also review it.
We’d next look for the document shepherd. :)
Thanks,
Jasdip
From: Antoin Verschuren
Date: Tuesday, February 4, 2025 at 11:57 AM
To: regext
Subject: [regext] Re: CALL FOR ADOPTI
+1 for adoption.
Thanks,
Jasdip
From: James Galvin
Date: Monday, February 3, 2025 at 9:06 AM
To: Registration Protocols Extensions
Subject: [regext] CALL FOR ADOPTION: draft-yao-regext-epp-quic and
draft-loffredo-regext-epp-over-http
Continuing our potential adoption of new documents, as previ
Hi Orie,
Version 09 of this draft now submitted.
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-09
Thanks,
Jasdip
From: Jasdip Singh
Date: Monday, February 3, 2025 at 10:36 AM
To: Orie
Cc: regext@ietf.org
Subject: [regext] Re: AD Evaluation: draft-ietf
m/jasdips/rdap-geofeed/blob/main/draft-ietf-regext-rdap-geofeed.md
From: Orie
Date: Saturday, February 1, 2025 at 4:18 PM
To: Jasdip Singh
Cc: regext@ietf.org
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
Hi Jasdip,
That text works for me.
Regards,
OS
On Sat, Feb
From: Orie
Date: Friday, January 31, 2025 at 9:42 AM
To: Jasdip Singh
Cc: regext@ietf.org
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
## Nits
### Reads awkwardly
```
249 inetnum objects (per [RFC9632]), clients who find a geofeed link
250 object within an
Hi Orie,
Thanks for your review! Tom and I discussed it. Please see our comments below.
Regards,
Jasdip
From: Orie
Date: Tuesday, January 28, 2025 at 12:37 PM
To: regext@ietf.org
Subject: [regext] AD Evaluation: draft-ietf-regext-rdap-geofeed-08
# Orie Steele, ART AD, comments for draft-ietf-
“I would certainly advise the authors to seek support in the SIDROPS WG by
presenting in the SIDROPS session and ask for review in our WG for this draft.
We think it will be an opportunity for us to seek more participation from other
participants in REGEXT outside DNRs.”
Thanks for this suggest
Hi Scott,
From: Hollenbeck, Scott
Date: Monday, January 27, 2025 at 2:32 PM
To: ietf=40antoin...@dmarc.ietf.org ,
regext@ietf.org
Subject: [regext] Re: CALL FOR ADOPTION: draft-jasdips-regext-rdap-rpki
[SAH] I support adoption of this draft, but I do have a concern. As far as I
know, there's
Hi,
From: kowa...@denic.de
Date: Friday, January 10, 2025 at 12:58 PM
To: Andrew Newton (andy)
Cc: regext@ietf.org
Subject: [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:
>>
From: Andrew Newton (andy)
Date: Tuesday, January 14, 2025 at 11:52 AM
To: Keathley, Daniel
Cc: regext@ietf.org
Subject: [regext] Re: Review of draft-ietf-regext-rdap-extensions-04 (Section
2.1.1 para 1)
On Mon, Dec 16, 2024 at 9:33 AM Keathley, Daniel
wrote:
> [DJK] There was some similar d
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. As it relates to
>> issuing URLs for redirects, servers MUST N
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/58
>> Section 4.4, paragraph 3
>> 2. Normative references, i.e. references to materials that are required for
>> the interoperability of the extension, should be stable and non-changing.
> Isn't this what rfc3967 actually define
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/57
>> Section 4.3, paragraph 2
>> If a future RFC defines a versioning scheme, an RDAP extension definition
>> MUST explicitly denote its compliance with that scheme.
> I think this one must be more specific. "Future RFC" is vagu
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 provision in
>> this respect, clients MUST assume the infor
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/54
>> Section 2.5, paragraph 0
>> 2.5. Identifier Omission
> What is a practical difference between this case and a registered bare
> identifier in 4.5?
[JS] Did you mean 2.4.5? Perhaps the section title can be better.
[TH] I
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/53
>> Section 2.4.7, paragraph 1
>> The styling convention used in [RFC9083] for JSON names is often called
>> "camel casing", in reference to the hump of a camel. In this style, the
>> first letter of every word, except the fir
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/52
>> Section 2.4.5, paragraph 1
>> 2.4.5. Bare Extension Identifiers
>>
>> Some RDAP extensions define only one JSON value and do not prefix it with
>> their RDAP extension identifier, instead using the extension identifier as
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/51
>> Section 2.3.2, paragraph 4
>> not required. In this situation, the URL path operates as a namespace for
>> the query parameters, so there is no risk of collision with parameters
>> defined elsewhere.
> There is a potenti
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
>> explicitly note that extension identifiers are case
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/49
>> Section 2.2, paragraph 3
>> RDAP extensions MUST NOT define an extension identifier that when prepended
>> to an underscore character may collide with an existing extension
>> identifier. For example, if there were a pre-e
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/48
>> Section 2.1.2, paragraph 1
>> Extension specifications have customarily defined only one extension
>> identifier. However, there is no explicit limit on the number of extension
>> identifiers that may be defined in a singl
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/47
>> Section 2.1, paragraph 2
>> The main purpose of the extension identifier is to act as a namespace,
>> preventing collisions between elements from different extensions.
>> Additionally, implementers and operators can use th
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/46
>> Section 2.1.1, paragraph 1
>> Some extensions exist to denote the usage of values placed into an IANA
>> registry, such as the IANA RDAP registries, or the usage of extensions for
>> specifications used in RDAP responses, s
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/45
>> Section 2.1, paragraph 2
>> When in use in RDAP, extension identifiers are prepended to URL path
>> segments, URL query parameters, and JSON object member names (herein
> "are prepended" seems to exclude bare identifiers. A
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/44
>> Section 5, paragraph 9
>> Client authors should be aware that responses that make use of these
>> extensions may require special handling on the part of the client. Also,
>> while these extensions will be retained in the r
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/43
>> Section 4.3.2, paragraph 1
>> With the current extension model, an extension with a backwards-incompatible
>> change is indistinguishable from a new, unrelated extension. Implementers
>> of such changes should consider the
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/42
>> Section 2.5, paragraph 2
>> RDAP extensions not defined by the IETF MUST use the extension identifier as
>> a prefix in accordance with this document, [RFC7480],
> I'm not very much convinced if this requirement is practica
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 RDAP query using the
>> path to return a new RDAP search
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/40
> Section 2.4.3, paragraph 3
>> It is RECOMMENDED that object class names comprise lowercase ASCII
>> characters, and that the "_" (underscore) character be used as a word
>> separator. Though "objectClassName" is a string an
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 policy (for example,
>> specifying the conditions of use
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/38
> Section 1, paragraph 1
> The Registration Data Access Protocol (RDAP) defines a uniform means
[TH] I think this is complaining about singular 'a' with ostensibly plural
'means', i.e. it's a false positive.
> Section 2.3.2,
Hi Pawel,
Firstly, thank you for your rich feedback. :) Tom, Andy, and I have reviewed
it, and to help systematically address it, created related issues (including
our comments) on GitHub [1]. Per your suggestion, would next send a separate
email message for each issue, to help facilitate focus
nothing more for now from the RIRs side. :)
Thanks for pointing to the NIC BR’s EPP extensions.
Jasdip
From: Rubens Kuhl
Date: Friday, December 13, 2024 at 2:29 PM
To: Jasdip Singh
Cc: Rubens Kuhl , Gould, James
, regext@ietf.org ,
r...@ietf.org
Subject: [regext] Re: [rpp] Re: EPP Extensibility
Hi Rubens,
Since couple of these involve number resource provisioning, curious if it is
desired from the NIC BR perspective that these use cases be considered upfront
for RPP?
Thanks,
Jasdip
From: Rubens Kuhl
Date: Friday, December 13, 2024 at 1:20 PM
To: Gould, James
Cc: regext@ietf.org , r
James,
Did you mean to address Pawel? :)
Jasdip
From: Gould, James
Date: Thursday, November 14, 2024 at 11:15 AM
To: kowa...@denic.de , mario.loffr...@iit.cnr.it
, Jasdip Singh , regext@ietf.org
Subject: Re: Re: [regext] Re: RDAP versioning draft feedback
Jasdip,
I believe that we can
Hi James, Daniel, Mario,
I read the latest draft and to help tighten this spec, have few higher-level
comments.
VCHAR use:
In section 3.1, the ABNF for “versioning” in “extension-version-identifier” is
“["-" 1*VCHAR]”. Since the extension version identifiers could be passed in the
“extensions
Hi.
FYI. Per Gavin’s shepherd feedback, submitted this request to
media-ty...@ietf.org<mailto:media-ty...@ietf.org> for a review of the new
geofeed media type.
Thanks,
Jasdip
From: Jasdip Singh
Date: Wednesday, October 23, 2024 at 10:27 AM
To: media-ty...@ietf.org
Cc: Tom Harrison ,
Hi Pawel,
Beside the discussion with Tom, want to highlight one other point you made.
Thanks,
Jasdip
From: kowa...@denic.de
Date: Monday, October 21, 2024 at 3:30 AM
To: regext@ietf.org
Subject: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search
Also 2.3.1 of draft-ietf
-rdap-geofeed-08.txt is now available. It is a
work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
Title: An RDAP Extension for Geofeed Data
Authors: Jasdip Singh
Tom Harrison
Name:draft-ietf-regext-rdap-geofeed-08.txt
Pages: 13
Dates
beck, Scott
Date: Friday, October 11, 2024 at 8:19 AM
To: mario.loffredo=40iit.cnr...@dmarc.ietf.org
, Jasdip Singh ,
a...@hxr.us , regext@ietf.org
Subject: RE: Re: [regext] Re: Extension Identifiers in
draft-ietf-regext-rdap-rir-search
From: Mario Loffredo
Sent: Friday, October 11, 2024 2:44 A
To: Andy Newton , Jasdip Singh
Subject: New Version Notification for draft-jasdips-regext-rdap-rpki-00.txt
A new version of Internet-Draft draft-jasdips-regext-rdap-rpki-00.txt has been
successfully submitted by Jasdip Singh and posted to the
IETF repository.
Name: draft-jasdips-regext-rdap
That’s fair, Scott.
BTW, so would be Reverse Search, until the Extensions draft updates STD 95
vis-à-vis the additional use-extension-id-as-segment-for-child-segments
approach.
Jasdip
From: Hollenbeck, Scott
Date: Wednesday, October 9, 2024 at 3:30 PM
To: Jasdip Singh , a...@hxr.us , regext
We agree. :)
Jasdip
From: Hollenbeck, Scott
Date: Wednesday, October 9, 2024 at 12:30 PM
To: Jasdip Singh , a...@hxr.us , regext@ietf.org
Subject: RE: [regext] Re: Extension Identifiers in
draft-ietf-regext-rdap-rir-search
From: Jasdip Singh
Sent: Wednesday, October 9, 2024 11:54 AM
To
Scott,
Glad to know that you are not against the
use-extension-id-as-segment-for-child-segments approach, beside the
prepend-extension-id-and-underscore approach from STD 95.
Re: “The “domains” collision is an issue. We can deal with it now, or during
IETF last call.”
AFAICT, it is not an iss
, 2024 at 11:41 AM
To: Jasdip Singh , regext@ietf.org
Subject: Re: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
Jasdip,
The use of sub-paths was not an envisioned form of extension in the base RFCs
as is the case for the other forms of extension that I included in my prior
From: Hollenbeck, Scott
Date: Tuesday, October 8, 2024 at 7:48 AM
To: Jasdip Singh , a...@hxr.us , regext@ietf.org
Subject: RE: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
From: Jasdip Singh
Sent: Monday, October 7, 2024 4:52 PM
To: Hollenbeck, Scott ; a...@hxr.us; rege
Scott,
From: Hollenbeck, Scott
Date: Monday, October 7, 2024 at 4:15 PM
To: Jasdip Singh , a...@hxr.us , regext@ietf.org
Subject: RE: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
…
I've read draft-ietf-regext-rdap-extensions-04 completely and have several
commen
Hi.
Please see my comments, marked [JS].
Jasdip
From: Hollenbeck, Scott
Date: Monday, October 7, 2024 at 11:42 AM
To: a...@hxr.us , regext@ietf.org
Subject: [regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04
From: Andrew Newton (andy)
Sent: Monday, October 7, 2024 6:41 AM
T
From: Andrew Newton (andy)
Date: Thursday, October 3, 2024 at 8:19 AM
To: Hollenbeck, Scott ,
regext@ietf.org
Subject: [regext] Re: Comments Regarding draft-ietf-regext-rdap-extensions-04
2.4.6:
"A strict interpretation of this wording where "construction of the response"
refers to th
Hi Antoin, Jim,
Though not for agenda, couple of items:
* Now that draft-ietf-regext-rdap-rir-search-09 and
draft-ietf-regext-rdap-geofeed-07 are past the WGLC period, would appreciate
knowing about the next step(s).
* Noticed that draft-ietf-regext-rdap-rir-search-09 recently expired.
Hi James,
Andy and I reviewed your note and believe it would be better to keep the RDAP-X
and Versioning drafts separate.
The RDAP-X media type leverages the standard HTTP content negotiation using the
Accept and Content-Type headers and is guaranteed to seamlessly work for any
RDAP response s
Internet-Draft draft-ietf-regext-rdap-geofeed-06.txt is now available. It is a
work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
Title: An RDAP Extension for Geofeed Data
Authors: Jasdip Singh
Tom Harrison
Name:draft-ietf-regext-rdap-geofeed-06.txt
find a geofeed link
object within an IP network object MUST ignore geofeed data from that
link that is outside the IP network object's address range.”
Hope this helps clarify.
Thanks,
Jasdip
From: Andrew Newton (andy)
Date: Monday, July 22, 2024 at 3:30 PM
To: Jasdip Singh
Cc: REGEXT Workin
Hi James,
Thanks for this feedback. Yes, Tom and I also think that replacing RECOMMENDED
with MUST should help tighten the spec. For details, please see my response to
Andy’s question #3 in the other thread.
Jasdip
From: Gould, James
Date: Friday, July 19, 2024 at 8:28 AM
To: gal...@elistx.co
Hi Andy,
Thanks for these insightful questions. Tom and I discussed them. Let me try
answering. :)
Tom, please add/subtract if needed.
Jasdip
From: Andrew Newton (andy)
Date: Thursday, July 18, 2024 at 3:19 PM
To: REGEXT Working Group , Jasdip Singh ,
t...@apnic.net
Subject: [regext] Re
Thanks, Mario. Will make the section 3 change in the next version.
Jasdip
From: Mario Loffredo
Date: Wednesday, July 17, 2024 at 3:16 AM
To: Jasdip Singh , regext@ietf.org
Subject: [regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05
Il 17/07/2024 01:01, Jasdip Singh ha scritto:
Hi Mario
Hi Mario,
From: Mario Loffredo
Date: Tuesday, July 16, 2024 at 9:56 AM
To: regext@ietf.org
Subject: [regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05
Have reviewed this document.
Per what is stated in section 3, it's not clear to me what servers should do
whenever the geofeed file exposes
Thanks, Jim.
Jasdip
From: James Galvin
Date: Wednesday, July 10, 2024 at 5:02 PM
To: Jasdip Singh
Cc: regext@ietf.org
Subject: [regext] Re: WGLC request for RIR Search and RDAP Geofeed drafts
Thanks Jasdip.
We’ll do these in parallel as soon as we get “delete-bcp” closed up.
Jim and Antoin
used, prevent the redaction of a single item.
From: Mario Loffredo
Date: Tuesday, June 18, 2024 at 3:33 AM
To: Jasdip Singh
Cc: regext@ietf.org
Subject: [regext] Re: Fwd: New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
Hi Jasdip,
AFAIU, the name.type
Good to know, Gavin. :)
Jasdip
From: Gavin Brown
Date: Monday, June 17, 2024 at 7:46 AM
To: Jasdip Singh
Cc: Registration Protocols Extensions
Subject: Re: [regext] [Ext] New Version Notification for
draft-brown-rdap-referrals-00.txt
Hi Jasdip,
> On 24 May 2024, at 17:58, Jasdip Si
17, 2024 at 10:38 AM
To: Jasdip Singh , mario.loffr...@iit.cnr.it
Cc: regext@ietf.org
Subject: Re: Re: [regext] Re: Fwd: New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
From: Gould, James
Date: Monday, June 17, 2024 at 7:47 AM
To: Jasdip Singh
Hi James,
Please find my comments below.
Thanks,
Jasdip
From: Gould, James
Date: Monday, June 17, 2024 at 7:47 AM
To: Jasdip Singh , mario.loffr...@iit.cnr.it
Cc: regext@ietf.org
Subject: Re: [regext] Re: Fwd: New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537
there. :)
Thanks,
Jasdip
From: Mario Loffredo
Date: Tuesday, June 11, 2024 at 6:27 AM
To: Jasdip Singh , Andrew Newton (andy) ,
regext@ietf.org
Subject: Re: [regext] Re: Fwd: New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
Hi Jasdip,
I'm inclined to
d in 5.1.1 with a clear recommendation for the
client implementers. Not enough?
[1] https://mailarchive.ietf.org/arch/msg/regext/nP9BZFbwhOkgiMim9s5upRqCYRs/
Kind Regards,
Pawel
On 11.06.24 06:28, Jasdip Singh wrote:
Hi.
It is a bit unfortunate for us as a WG that we missed the fundamental
short
Hi.
It is a bit unfortunate for us as a WG that we missed the fundamental
shortcomings of the JSONPath usage for redaction, as highlighted in the draft
below. Especially, the “prePath” portion where a client would have no idea
about how to apply that expression to the response in hand. Though t
1 - 100 of 223 matches
Mail list logo
