> Le 9 juin 2022 à 16:32, Takahiro Nemoto via Datatracker a
> écrit :
>
> Reviewer: Takahiro Nemoto
> Review result: Ready with Issues
>
> I am the assigned ART-ART reviewer for this draft.
>
> Summary:
> I think this document is concise and generally good, but a few things are not
> explain
> Le 1 août 2022 à 09:49, James Galvin a écrit :
>
> As everyone knows there has been quite some discussion on the mailing list
> regarding how to implement rdapConformance. This was a significant topic of
> discussion at the REGEXT meeting during IETF114.
>
> Three options were proposed on
> Le 29 août 2022 à 10:01, Hollenbeck, Scott
> a écrit :
>
> I originally made this request in a note to the list on 18 August:
>
> https://mailarchive.ietf.org/arch/msg/regext/DhG25zCOF4RoR5TukZIg_CLzjrU/
>
> The request might have been lost or missed given the different subject on
> that m
> Le 11 oct. 2022 à 09:04, Andrew Newton a écrit :
>
> On Tue, Oct 11, 2022 at 8:16 AM Mario Loffredo
> wrote:
>>
>> my humble opinion is that this document shouldn't deal with any kind of RDAP
>> client other than a browser.
>
> At the moment, I disagree with this. Authentication for non-b
A suggestion to get the final word and to reply to your registrar: Use an XML
schema checker, feed it with the schema and the XML message you receive and
then look at the result of the parsing: it would tell you if the xml source is
valid against the schema. An example of such tool is xmllint —
TC−4
> À: "Marc Blanchet"
>
>
> A new version of I-D, draft-blanchet-regext-rdap-space-00.txt
> has been successfully submitted by Marc Blanchet and posted to the
> IETF repository.
>
> Name: draft-blanchet-regext-rdap-space
> Revision: 00
>
Marc.
>
> -andy
>
> On Mon, Oct 24, 2022 at 4:32 PM Marc Blanchet
> wrote:
>>
>> Hello,
>> A (new) use case for RDAP for different kind of objects. This is still
>> preliminary.
>>
>> Marc.
>>
>> Début du message transféré :
Sorry I was not able to attend. But reading the slides, I just want to make
sure the mobile app RDAP client is properly taken into account. I think this is
the « CLI » use case described, but just want to make sure we properly cover
the mobile app RDAP client (I wrote one… and intend to implemen
bout « pure » mobile apps.
One can also think of a mobile app like a desktop app. No difference to me.
Both are http clients.
Regards, Marc.
> , then it's the same as a browser app - just no clue how the cookies are
> handled: same-site or cross-site, but likely you can control it i
> Le 14 nov. 2022 à 09:09, Hollenbeck, Scott
> a écrit :
>
> We need to decide what to do with draft-ietf-regext-rdap-openid and web
> service clients. Our choices:
>
> 1. Finish the draft as-is, noting that it's limited to clients that can
> implement OpenID Connect flows and can process s
> Le 15 nov. 2022 à 10:50, Pawel Kowalik a écrit :
>
> Hi Scott,
>
> Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott:
>> [SAH] Based on the testing you and I've been doing, we already know that web
>> service clients require token processing features that aren't currently
>> specified. That's f
> 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 redaction by empty value would not be compliant with the
> Le 16 janv. 2023 à 10:43, Pawel Kowalik a écrit :
>
> 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,
>>>
>
> Le 16 janv. 2023 à 16:18, Pawel Kowalik a écrit :
>
> Hi Marc,
>
> Comment below
>
> Am 16.01.23 um 16:49 schrieb Marc Blanchet:
>>
>>>>> Le 11 janv. 2023 à 12:43, Gould, James
>>>>> a écrit :
>>>>>
>>>
To NRO RDAP people (since I don’t know to who should I send it),
I’m seeing with my RDAPBrowser client that you guys are sending the following
objects in RDAP responses:
links: [
{
…
rel: “inaccuracy-report”
However, that value is not registered in the IANA Link Relations registry
(https:
> Le 30 mars 2023 à 19:47, Mario Loffredo a écrit :
>
> Hi folks,
>
> this is a post to resume the discussion about how to execute the transition
> from jCard to JSContact.
>
> Up to now, there are two approaches on the table:
>
>
> 1) Returning JSContact in place of jCard (current proposa
> Le 31 mars 2023 à 08:32, Hollenbeck, Scott
> a écrit :
>
>> -Original Message-
>> From: regext On Behalf Of Mario Loffredo
>> Sent: Friday, March 31, 2023 7:45 AM
>> To: regext@ietf.org
>> Subject: [EXTERNAL] [regext] Redacting JSContact uid in RDAP - Updated
>>
>> Caution: This em
> Le 7 juin 2023 à 14:26, Andrew Newton a écrit :
>
> Hi All,
>
> Very recently I have had the displeasure of implementing jCard for an
> RDAP client, and in so doing have taken a closer look at JSContact and
...
>
> #3 JSContact Implementations and Scope
>
> I did a little hunting around f
> Le 7 juin 2023 à 14:26, Andrew Newton a écrit :
>
> Hi All,
>
...
> By contrast, JSContact JSON objects are much more than simple JSON
> objects as found in RDAP. Here is an example of JSContact person
> titles:
>
> "titles": {
> "le9": {
>"kind": "title",
>"name": "Research Scien
> Le 26 juin 2023 à 10:02, James Galvin a écrit :
>
> 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 for the Registration Data Access Protocol (RDAP)
> Le 12 juill. 2023 à 09:35, Andrew Newton a écrit :
>
> Thanks for the review Pawel. My response is in-line:
>
> On Wed, Jul 12, 2023 at 2:41 AM Pawel Kowalik wrote:
>>
>
>>
>> The last question to the discovery part. Shall client have a possibility
>> to find out support for this extensi
> Le 14 nov. 2023 à 13:52, Andrew Newton a écrit :
>
> On Tue, Nov 14, 2023 at 9:02 AM Gould, James wrote:
>>
>> Andy,
>>
>> I recommend covering the use of query parameters in RDAP in the
>> draft-newton-regext-rdap-extensions, since it's unclear and deserves
>> discussion on the mailing l
> Le 17 nov. 2023 à 05:53, Mario Loffredo a écrit :
> I strongly disagree about having two specs with the same puropose and I do
> believe that the WG should take the responsibility to decide what is mostly
> suitable for RDAP now and for the future.
>
+1. We shall only have one spec and dep
Hello,
As I’m currently working on a new version of RDAP Browser (a mobile RDAP
client on iOS and Android), I would like to know if some registries (either
domain or RIR) have or are about to implement draft-ietf-regext-redacted as it
is on its way to RFC. I would like to test my client on thei
at which point I'm happy to come back to you again to run your
> clients against our "test" implementation.
Great. Looking forward to it.
Marc.
>
> Best,
> Alex
>
>
> -Ursprüngliche Nachricht-
> Von: regext Im Auftrag von Marc Blanchet
&g
> Le 19 févr. 2024 à 20:28, James Mitchell a écrit :
>
> Hi all,
>
> IANA is planning to add the DNS root to the RDAP DNS bootstrap file. We do
> not yet have a date for this change and are currently looking to understand
> potential impact to RDAP clients.
>
Hi James,
Thanks for letti
gext-boun...@ietf.org>> on
> behalf of James Mitchell <mailto:james.mitch...@iana.org>>
> Date: Tuesday, February 20, 2024 at 11:42 AM
> To: Marc Blanchet <mailto:marc.blanc...@viagenie.ca>>
> Cc: "regext@ietf.org <mailto:regext@ietf.org>" <
It appears to me that we are putting the carriage before the horse in this
discussion. I would suggest to write a milestone like “a RESTy EPP” but not too
much details to leave room for what it will finally be, and leave the
discussion on how it is implemented, how much it is really an EPP tran
> Le 24 mai 2024 à 08:10, Gavin Brown a écrit :
>
> Hi all,
>
> With my RDAP client implementer hat on, I've been ruminating about how the
> users of my client(s)[1] use them, and some anecdata suggests that in
> general, consumers of registration data - in the domain space at least - are
>
> Le 24 mai 2024 à 12:04, Gould, James a
> écrit :
>
> Gavin,
>
> I mirror the other feedback with the concern over duplicating the link
> information in the response header that is included in the response body for
> the HTTP GET. It would be best just to support the HTTP HEAD,
Right, bu
od are different forms of removal, so they
> can be grouped in the removal bucket for the end users.
>
> Is there any other experience from client implementers (e.g., Marc Blanchet)
> that can be shared?
I’ve been busy on other projects, so redaction is on my todo list. I did some
i
items, and do you view any inherent issues
> in using this information from the RDAP response?
>
> Thanks,
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com
>
>
> 703-948-3271
> 12061 Bluemont Way
&
> Le 17 juin 2024 à 07:45, Gavin Brown a écrit :
>
> Hi Marc,
>
>> On 24 May 2024, at 14:17, Marc Blanchet wrote:
>>
>>>
>>> Le 24 mai 2024 à 08:10, Gavin Brown a écrit :
>>>
>>> Hi all,
>>>
>>> With my RDAP
On 29 Jul 2016, at 8:01, Ulrich Wisser wrote:
Here are the "new" minutes. Please check if your comments were fixed.
draft-ietf-regext-bundling-registration
I said on the mike that I think we shall not have multiple bundling
extensions on standard track. We shall find a way to merge the
req
On 10 Aug 2016, at 17:45, Brian Mountford wrote:
> RFC 7482 doesn't seem to indicate how Unicode characters are to be
> specified when searching for entities by name. Should the name be
> punycoded?
punycode is really only for domain names.
Marc.
> Passed as encoded Unicode? Either way?
>
> T
On 5 Oct 2016, at 5:10, Patrik Fältström wrote:
On 5 Oct 2016, at 10:56, Alexey Melnikov wrote:
To followup on my previous reply:
On 5 Oct 2016, at 08:16, Patrik Fältström wrote:
Based on your comments, it appears that this
I-D should be an informational document, and I have no objection
I have a problem with how this document is presented. A reading seems to
indicate that the protocol itself has nothing to do with the specific
country cited or the language used in that country, which I think is
good: it is a generic specification. Moreover, I see a statement saying
that this d
I have said on the mike two meetings ago that there are multiple
bundling drafts and instead of having many, the co-authors should work
on a common framework/document. There has been some initial
communications between them offline but more to come. I would suggest
that we shall work towards a
On 7 Dec 2016, at 10:20, Andrew Newton wrote:
On Wed, Dec 7, 2016 at 10:12 AM, Andrew Sullivan
wrote:
I will just point out that this is the _exact_ reason some of us
thought the bootstrap mechanism should have been SRV records in the
DNS, because it would have neatly solved that exact problem
On 31 Jul 2017, at 14:50, Roger D Carney wrote:
Good Afternoon,
I just wanted to start (continue) the discussion about having two
sessions for REGEXT at IETF meetings. As many of you heard me say in
Prague, I thought that the extra working session that we had in
Chicago was very productive a
Thanks for reporting this. You are right that the intent of the example
was not as written. It should have been as you pointed:
https://example.net/rdap/xn--zckzah
So I would agree with the proposed change.
Regards, Marc.
On 14 Aug 2018, at 8:14, RFC Errata System wrote:
The following errata
Hello,
thanks for reporting this. The original text was meant as some
possible guidance on what to do for the implementor. However, the use of
may and could in the text shows clearly that this is just one
possibility, leaving the implementor more complex implementation
algorithm. I’m not sure
.
The draft is not fully baked but more than enough to have a discussion
on the issue and the proposed solution.
Looking for comments and reviews,
Marc.--- Begin Message ---
A new version of I-D, draft-blanchet-regext-entityid2rdapserver-00.txt
has been successfully submitted by Marc Blanchet and
On 25 Feb 2019, at 12:46, Tongfeng Zhang wrote:
At .ca and all the TLDs CIRA operates, we have a similar feature of
registry lock.
We are interested in standardization for sure.
There is a regiOps workshop coming up in May in Bangkok. I see a fit
there
Good idea. We have issued a call for
Update
Author : Marc Blanchet
Filename: draft-blanchet-regext-rdap-deployfindings-00.txt
Pages : 10
Date: 2019-06-02
Abstract:
Registration Access Data Protocol(RDAP) is being deployed in domain
and IP address registries. This
On 3 Jun 2019, at 8:33, Mario Loffredo wrote:
I don't completely agree with you about the content of section 6.1. If
we read the definition of search patterns based on a name in
RFC7482, it seems that, even in these cases, partial matching would
not be allowed since the pattern should repr
FYI, some new findings added.
Marc.--- Begin Message ---
A new version of I-D, draft-blanchet-regext-rdap-deployfindings-02.txt
has been successfully submitted by Marc Blanchet and posted to the
IETF repository.
Name: draft-blanchet-regext-rdap-deployfindings
Revision: 02
Title
There has been discussion on replacement of jcard. One of the
considerations in the equation is how to handle the migration. Some
people have (appropriatly) expressed concerns about this issue of
migration. While I’m not yet sure if we need to deprecate jcard, I
would like to suggest a way to m
contact representation is
provided by the server in the response.
2) The clients transitions from jcard to jscard don’t depend on
server transition.
3) At any moment, the response would be compliant with RFC7483
Best,
mario
Inviato da iPhone
Il giorno 25 lug 2019, alle ore 16:20, Marc
Hello,
sorry for the cross-posting and announcement.
Just to tell that the RDAPBrowser app is now available on both ios and
android respective app stores.
(For tech-savvy people, the app UX does not show all possible fields
received in the JSON, but most of them, on purpose. The received JSO
On 29 Aug 2019, at 4:11, Marc Groeneweg wrote:
All,
Due to the release of the mobile app of Marc, Blanchet we saw we
differ in interpretation of some fields we have in our RDAP
implementation (for .politie and .amsterdam).
Feedback from my development on the issues given Marc is that they
On 29 Aug 2019, at 4:11, Marc Groeneweg wrote:
So, we have our implementation live! But how can we make sure (if not
ICANN but at least the community) what compliancy means... (e.g. we
return a null when we don't have a value and "" when we have an empty
string value. The mobile app wants "" i
Hello,
as Scott is updating RFC7482,RFC7483 for standard level, I’m doing
the same for rfc7484. I haven’t heard major issues or major fixes to
be made for rfc7484. I have a few wording fixes only at this time. There
were some discussions on enhancing RFC7484 for other use cases, but
never wen
On 4 Aug 2020, at 15:32, Gavin Brown wrote:
Hi Marc,
as Scott is updating RFC7482,RFC7483 for standard level, I’m doing
the same for rfc7484. I haven’t heard major issues or major fixes
to be made for rfc7484. I have a few wording fixes only at this time.
There were some discussions on enh
On 4 Aug 2020, at 12:47, Patrick Mevzek wrote:
On Tue, Aug 4, 2020, at 08:46, Marc Blanchet wrote:
if anyone has a something to raise for RFC7484, please send me
email
asap.
Hello Marc,
Also about:
"
Because these registries will be accessed by software, the download
demand fo
On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
> On Tue, Aug 4, 2020, at 14:32, Gavin Brown wrote:
>> 1. client implementers should be advised to prefer https:// base URLs
>> over http:// base URLs.
>
> I think this is already addressed by this text in the current RFC:
> "
>Per [RFC7258], in e
On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
PS: related but not directly, at least for domain registries, it would
be
nice to have an `SRV` record on `_rdap._tcp` or something to point to
relevant
RDAP server, even if that does not allow to encode the path (but maybe
a solution with .well-
comments.
Would like to see it adopted by the wg so we can push it for Full
Standard.
Marc.
Forwarded message:
From: internet-dra...@ietf.org
To: Marc Blanchet
Subject: New Version Notification for
draft-blanchet-regext-rfc7484bis-00.txt
Date: Tue, 11 Aug 2020 13:13:28 -0700
A new version
On 12 Aug 2020, at 11:25, Gavin Brown wrote:
On 11 Aug 2020, at 19:33, Marc Blanchet
wrote:
On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
On Tue, Aug 4, 2020, at 14:32, Gavin Brown wrote:
1. client implementers should be advised to prefer https:// base
URLs
over http:// base URLs.
I
On 11 Aug 2020, at 15:27, Patrick Mevzek wrote:
Hello Marc,
On Tue, Aug 11, 2020, at 13:55, Marc Blanchet wrote:
On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
PS: related but not directly, at least for domain registries, it
would
be
nice to have an `SRV` record on `_rdap._tcp` or
Hello,
for the rdap bootstrap registries, there has been (well since the very
beginning of the work) discussions about only supporting https URLs.
I’m happy to make it mandatory. Is there a working group agreement on
this? Please speak up if you don’t agree (i.e. you still want no TLS
http).
n you provide some text or some proposal on that
matter?
Marc.
-G
On Thu, Aug 13, 2020 at 9:40 PM Gavin Brown
wrote:
On 12 Aug 2020, at 17:18, Marc Blanchet
wrote:
well, already added text in the published draft yesterday.
https://www.ietf.org/internet-drafts/draft-blanchet-r
On 10 Feb 2021, at 13:23, James Galvin wrote:
Thanks to all who indicated support for this document. There is a
consensus for the working group to adopt this document. It has been
supported by Jasdip Singh, Mario Loffredo, Scott Hollenbeck, Alexander
Mayrhofer, and Maurizio Maretinelli.
Ja
the IETF.
Title : Finding the Authoritative Registration Data
(RDAP) Service
Author : Marc Blanchet
Filename: draft-ietf-regext-rfc7484bis-01.txt
Pages : 18
Date: 2021-03-09
Abstract:
This document
On 10 Mar 2021, at 8:51, Hollenbeck, Scott wrote:
Some minor things after reading through the document:
thanks!
Section 2: there's new(er) boilerplate for the BCP14 text. See 7482bis
or 7483bis for the new text.
thanks. applied.
Section 6: I think it's worth noting the existence of
On 19 Mar 2021, at 16:19, Hollenbeck, Scott wrote:
-Original Message-
From: Marc Blanchet
Sent: Friday, March 19, 2021 4:13 PM
To: Hollenbeck, Scott
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] 7484bis Feedback
[SAH] [snip]
Section 13: It might help to add a sentence to
Hello,
new version:
- added Scott Hollenbeck comments
- added ARIN implementation info from Jasdip Singh
Ready for wglc to me.
Regards, Marc.
Forwarded message:
From: internet-dra...@ietf.org
To: Marc Blanchet
Subject: New Version Notification for
draft-ietf-regext-rfc7484bis-02.txt
IPv4 and IPv6 formats in
sections 5.1 and 5.2.
Jasdip
On 3/19/21, 4:47 PM, "regext on behalf of Marc Blanchet"
wrote:
Hello,
new version:
- added Scott Hollenbeck comments
- added ARIN implementation info from Jasdip Singh
Ready for wglc to me.
Just read it. God. We need it. (Specially with my hat of RDAP client app).
Some early comments:
- would be good to include specific text about jscontact, so when we switch to
it, this document does not need rev.
- I really would like to have an IANA registry for the « reason » property.
Bec
ames Gould
> Fellow Engineer
> jgo...@verisign.com
>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 7/12/21, 7:15 AM, "Marc Blanchet" wrote:
>
>Just read it. God. We ne
approach taken in RFC 9083 and address
> your feedback?
Fine by me! Much better to me.
Marc.
>
> Thanks,
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com
>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 2
I’m not on jmap list, but I have to say that their proposed approach is much
more complicated to decode by standard json decoders. I would say don’t do it.
Marc.
> Le 21 juill. 2021 à 08:50, Mario Loffredo a écrit
> :
>
> I would like to invite the WG members to provide feedback about a topic
I think this work is really useful.
Marc.
> Le 16 août 2021 à 09:39, Antoin Verschuren a écrit :
>
> This is the formal adoption request for Redacted Fields in the Registration
> Data Access Protocol (RDAP) Response:
> https://datatracker.ietf.org/doc/draft-gould-regext-rdap-redacted/
>
> Pl
stration Protocols Extensions WG of the
> IETF.
>
>Title : Finding the Authoritative Registration Data (RDAP)
> Service
> Author : Marc Blanchet
> Filename: draft-ietf-regext-rfc7484bis-04.txt
> Pages : 20
>
> Le 6 déc. 2021 à 09:29, Antoin Verschuren a
> écrit :
>
> Hi all,
>
> In addition to the questions from Mario, we still need to discuss the status
> of this document as discussed during the IETF112 meeting:
>
> "the document doesn’t have designated status; it was adopted without a status
> Le 7 déc. 2021 à 08:35, Hollenbeck, Scott
> a écrit :
>
> We can *certainly* do that, Mario. It’s the option I support because there is
> a cost to replace a jCard implementation once it’s been implemented and
> deployed. Make it an optional extension and let server operators decide
> if/w
Hello,
Anyone on the server side has implemented redacted
(draft-ietf-regext-rdap-redacted-02 ) ? Just looking into implementing it on my
mobile client and wanted to know if I can try with some servers? Reply on the
list or direct to me, up to you.
Thanks, Marc.
___
tion Data (RDAP)
> Service
> Author : Marc Blanchet
> Filename: draft-ietf-regext-rfc7484bis-05.txt
> Pages : 20
> Date: 2022-01-25
>
> Abstract:
> This document specifies a method to find which Registration Data
&g
> Le 30 sept. 2021 à 17:29, Russ Housley via Datatracker a
> écrit :
>
> Reviewer: Russ Housley
> Review result: Ready
>
> I am the assigned ARTART reviewer for this Internet-Draft.
>
> Document: draft-ietf-regext-rfc7484bis-04
> Reviewer: Russ Housley
> Review Date: 2021-09-30
> IETF LC End
> Le 6 oct. 2021 à 15:08, Joel Halpern via Datatracker a
> écrit :
>
> Reviewer: Joel Halpern
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Ple
> Le 29 nov. 2021 à 05:22, Robert Wilton via Datatracker a
> écrit :
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To a
> Le 29 nov. 2021 à 09:01, Lars Eggert via Datatracker a
> écrit :
>
> Lars Eggert has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and C
> Le 1 déc. 2021 à 14:37, Erik Kline via Datatracker a écrit
> :
>
> Erik Kline has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC l
> Le 1 déc. 2021 à 21:05, John Scudder via Datatracker a
> écrit :
>
> John Scudder has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and
> Le 1 déc. 2021 à 05:39, Éric Vyncke via Datatracker a
> écrit :
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC line
> Le 29 nov. 2021 à 16:37, Benjamin Kaduk via Datatracker a
> écrit :
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and
> Le 25 janv. 2022 à 17:46, John Scudder a écrit :
>
> Hi Marc,
>
> Thanks, I just had a look at the diff. I have one further point to follow up
> on.
>
>> On Jan 25, 2022, at 5:22 PM, Marc Blanchet wrote:
>>
>>> Le 1 déc. 2021 à 21:05,
Hello,
As part of the reviews of draft-ietf-regext-rfc7484bis-04 for Internet
Standard, Benjamin Kaduk has commented as follows:
Section 3
The RDAP Bootstrap Service Registries, as specified in Section 13
below, have been made available as JSON [RFC8259] objects, which can
be retrieved v
> Le 29 nov. 2021 à 10:31, Francesca Palombini via Datatracker
> a écrit :
>
> Francesca Palombini has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included
queue.
Marc.
> Le 25 janv. 2022 à 18:58, Marc Blanchet a écrit :
>
> Hello,
> As part of the reviews of draft-ietf-regext-rfc7484bis-04 for Internet
> Standard, Benjamin Kaduk has commented as follows:
>
>
> Section 3
>
> The RDAP Bootstrap Service Registries, a
> Le 29 nov. 2021 à 16:37, Benjamin Kaduk via Datatracker a
> écrit :
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: Discuss
…
>
>
> Section 11
>
> The
> transport used
> Le 1 févr. 2022 à 19:51, Murray S. Kucherawy a écrit :
>
> On Tue, Jan 25, 2022 at 4:05 PM Marc Blanchet <mailto:marc.blanc...@viagenie.ca>> wrote:
> > 1. -
> >
> > FP: Please replace references to RFC 7234 with draft-ietf-httpbis-cache-19.
>
&
> Le 17 févr. 2022 à 08:24, Hollenbeck, Scott
> a écrit :
>
> From: regext On Behalf Of Hollenbeck, Scott
> Sent: Monday, February 14, 2022 12:12 PM
> To: jasd...@arin.net; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] I-D Action:
> draft-ietf-regext-rdap-openid-10.txt
>
> Caution: Th
> On Jan 31, 2025, at 06:20, Gavin Brown wrote:
>
> Greetings,
>
> I am seeking the wisdom of the WG on the following.
>
> Section 4 of RFC 9224 states that: (a) "the domain name's authoritative
> registration data service is found by doing the label-wise longest match of
> the target domain
Reviewer: Marc Blanchet
Review result: Ready with Issues
I was assigned by the Internationalization Directorate to do a review of this
document with a specific eye on internationalization and also a specific
request from AD to look at section 10.
I would like to point out that in some cases, the
95 matches
Mail list logo
