By the way,
I had to resend this a couple times, and finally use a .COM tld to get my mail
through.
Is the IETF is blocking the .LINK tld ?
```
This is the mail system at host zimbra1.uniregistry.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more rec
Hi *,
In my opinion, in order for RDAP to be successful, those use cases will
have to be taken into account. Regular users do use WHOIS to query for
availability, or if a name is unavailable they want to know why, I know
this first hand from feedback we received when we launched Uniregistry.
> Em 7 de dez de 2016, à(s) 20:13:000, Andrew Sullivan
> escreveu:
>
> On Wed, Dec 07, 2016 at 03:16:01PM -0200, Rubens Kuhl wrote:
>>
>> Unintuitive as it is, that was exactly the output of the ICANN EWG on RDDS.
>
> Perhaps fortunately, the EWG's output doesn't determine ICANN policy
> on t
On Wed, Dec 07, 2016 at 03:16:01PM -0200, Rubens Kuhl wrote:
>
> Unintuitive as it is, that was exactly the output of the ICANN EWG on RDDS.
Perhaps fortunately, the EWG's output doesn't determine ICANN policy
on this. Because the centralised RDS that they were proposing was,
IMO, very close to
> Em 7 de dez de 2016, à(s) 15:12:000, Gould, James
> escreveu:
>
> Andrew,
>
> Yes, RDDS is aware of the data but not of all the business rules that is
> needed to support the SRS. RDDS is a lookup protocol and just because there
> is one or some implementations out there that have include
Il 07/12/2016 18:12, Gould, James ha scritto:
Andrew,
Yes, RDDS is aware of the data but not of all the business rules that is needed
to support the SRS. RDDS is a lookup protocol and just because there is one or
some implementations out there that have included additional logic does not
mea
> Em 7 de dez de 2016, à(s) 15:04:000, Andrew Sullivan
> escreveu:
>
> On Wed, Dec 07, 2016 at 03:30:24PM +, Gould, James wrote:
>> It sounds like you’re attempting to morph RDDS into the SRS.
>
> Nope.
>
>> RDDS is a lookup service and the SRS is an OLTP system. A lookup
>> service eith
Andrew,
Yes, RDDS is aware of the data but not of all the business rules that is needed
to support the SRS. RDDS is a lookup protocol and just because there is one or
some implementations out there that have included additional logic does not
mean that it is a standard that “we” need to confor
On Wed, Dec 07, 2016 at 03:30:24PM +, Gould, James wrote:
> It sounds like you’re attempting to morph RDDS into the SRS.
Nope.
>RDDS is a lookup service and the SRS is an OLTP system. A lookup
> service either has the data or it doesn’t. Extra business logic
> associated with availability (
On Wed, Dec 07, 2016 at 10:20:20AM -0500, Andrew Newton wrote:
>
> I'm unaware of any HTTP clients that natively use SRV records (there
> may be some, but its far from the norm). To me, "neatly" is in the eye
> of the beholder. :)
I'm similarly unaware of any that know how to look things up in an
In article <20161207151238.gc27...@mx2.yitter.info> you write:
>On Wed, Dec 07, 2016 at 09:56:11AM -0500, John R Levine wrote:
>> I was thinking that you're the RDAP server for .FOO and someone who's
>> screwed up his bootstrap asks about BLAH.BAR, with whom you have no
>> connection.
>
>I will jus
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
It sounds like you’re attempting to morph RDDS into the SRS. RDDS is a lookup
service and the SRS is an OLTP system. A lookup service either has the data or
it doesn’t. Extra business logic associated with availability (variant
blocking, relationship blocking, reserved domains, etc.) should b
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.
I'm unaware of any HTTP clients that nat
On Wed, Dec 07, 2016 at 09:56:11AM -0500, John R Levine wrote:
> I was thinking that you're the RDAP server for .FOO and someone who's
> screwed up his bootstrap asks about BLAH.BAR, with whom you have no
> connection.
I will just point out that this is the _exact_ reason some of us
thought the bo
There are lots of reasons an RDAP server might not have info about a
domain, e.g., you ask it about a TLD it doesn't handle, and there's no
reason to assume that an RDAP server would know anything about an
unknown domain's availability.
I would think anybody doing reselling would have the availa
On Wed, Dec 7, 2016 at 9:19 AM, John Levine wrote:
> This is not a problem that RDAP is designed to solve.
In my opinion, with a few tweaks it could. We did sidestep the issue
in the original protocol design to keep the scope of the work small.
> There are lots of reasons an RDAP server might n
>If a client submits a query about a reserved or unassignable domain,
>which response code should the server return?
>
>In my opinion, if the server returns a 404 response, it could be
>misunderstood. The client could undestand the domain is available.
This is not a problem that RDAP is designed
> On Dec 7, 2016, at 5:48 AM, Mario Loffredo wrote:
>
> Hi all,
>
> I have a question about how to deal with RDAP lookup queries for reserved or
> unassignable domains.
>
> If a client submits a query about a reserved or unassignable domain, which
> response code should the server return?
>
Hi all,
I have a question about how to deal with RDAP lookup queries for
reserved or unassignable domains.
If a client submits a query about a reserved or unassignable domain,
which response code should the server return?
In my opinion, if the server returns a 404 response, it could be
mis
20 matches
Mail list logo
