How about this:
All RDAP endpoints referenced by the URLs in the array MUST return
identical responses for the same RDAP query, except that the “notices”
data structure MAY contain an object informing the client of the
identity of the endpoint. If such an object is provided it SHOULD use
the
On Fri, Aug 21, 2020 at 12:26:44PM -0400, Marc Blanchet wrote:
> 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 spe
On Fri, Aug 21, 2020, at 11:26, Marc Blanchet wrote:
> 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
On 16 Aug 2020, at 19:27, George Michaelson wrote:
I would like to see some allowance of limited metadata about which
node responded, or other information variance. If thats confined to
comments in the outer protocol, it means the response inline cannot be
used to debug specific problems with th
On Sun, Aug 16, 2020, at 21:08, Rubens Kuhl wrote:
> Of the 822 https:// URLs in https://data.iana.org/rdap/dns.json , and 0
> http:// URLs, there are some for ccTLDs:
> .ar
> .br
> .ca
> .cr
> ..cz
> .id
> .is
> .no
> .tz
>
>
> So, I believe we could remove http:// as a transport option, and th
> On 11 Aug 2020, at 16: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 o
I would like to see some allowance of limited metadata about which
node responded, or other information variance. If thats confined to
comments in the outer protocol, it means the response inline cannot be
used to debug specific problems with the node which responded.
We see this all the time in D
> 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-regext-rfc7484bis-00.txt
>
> extract of my added text:
> « All RDAP endpoints referenced by the URLs in the array MUST return
>
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 somethin
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 th
> 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 think this is already addres
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 something to point to
> > relevant
> > RDAP
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-
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 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 for the R
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 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 each array of base RDAP URLs, the secure versions
of
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 enhancing RFC7484 for other use cases, but n
In article you write:
>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,
>
>Maybe just an update regarding TLS:
>s/RFC5246/RFC8446/
>but depending on what IANA webservers support or not.
The curre
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,
Maybe just an update regarding TLS:
s/RFC5246/RFC8446/
but depending on what IANA webservers support or not.
Also about:
"
Because these registries
20 matches
Mail list logo
