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 recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<[email protected]>: host mail.ietf.org[4.31.198.44] said: 550 5.7.1
<[email protected]>: Sender address rejected: Blocked for spam,
please see http://www.ietf.org/secretariat.html (in reply to RCPT TO
command)
```
```
This is the mail system at host server.obispo.link.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<[email protected]>: host mail.ietf.org[4.31.198.44] said: 550 5.7.1
<[email protected]>: Sender address rejected: Blocked for spam, please
see http://www.ietf.org/secretariat.html (in reply to RCPT TO command)
```
On 7 Dec 2016, at 15:51, Francisco Obispo wrote:
> 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.
>
> for instance:
>
> ```
> $ whois -h whois.nic.link thisnameisavailable.link
> The queried object does not exist: Domain thisnameisavailable.link is
> available for registration.
>
>>>> Last update of WHOIS database: 2016-12-07T23:41:41.710Z <<<
>
> […]
>
> ```
>
> ```
> $ whois -h whois.nic.link iana.link
> The queried object does not exist: See below for more information
>>>> registry reserved
>
>>>> Last update of WHOIS database: 2016-12-07T23:42:27.510Z <<<
> […]
> ```
>
>
> ```
> $ whois -h whois.nic.link iana.foobarbaz
> The queried object does not exist: See below for more information
>>>> tld not supported by this registry interface
>
>>>> Last update of WHOIS database: 2016-12-07T23:42:43.702Z <<<
> […]
> ```
>
> ```
> $ whois -h whois.nic.link obispo.link
> Domain Name: obispo.link
> Domain ID: DO_d278b6e470d7fc1d3135e5261b65dc34-UR
> WHOIS Server: whois.uniregistry.net
> Referral URL: http://whois.uniregistry.net
> Updated Date: 2016-03-23T23:08:14.025Z
> Creation Date: 2014-04-15T16:14:20.513Z
> Registry Expiry Date: 2017-04-15T16:14:20.513Z
> […]
> ```
>
>
> Those use cases need to be preserved in the new system, we must be able to
> signal different responses based on the object situation, and as a registry,
> people expect this to be authoritative and accurate.
>
>
> regards,
>
>
>
> On 7 Dec 2016, at 7:30, Gould, James wrote:
>
>> 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 be
>> left to the appropriate channel which is the SRS and not RDDS.
>>
>> --
>>
>> JG
>>
>> James F. Gould
>> Distinguished Engineer
>> Verisign
>> [email protected]
>>
>>
>>
>> On 12/7/16, 10:12 AM, "regext on behalf of Andrew Sullivan"
>> <[email protected] on behalf of [email protected]> wrote:
>>
>> 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 bootstrap mechanism should have been SRV records in the
>> DNS, because it would have neatly solved that exact problem.
>>
>> > I suppose we could pick another code for "it's not assigned but if you
>> pay
>> > me money it could be" but I really don't think it's a good idea to read
>> > anything beyond "I don't know" into a normal 404 response.
>>
>> I agree with this in principle, but given the way humans actually use
>> the RDDS, there's going to need to be _some_ way to communicate this
>> difference. In particular, for policy reasons it's important to
>> understand "this domain isn't available because someone has it", "this
>> domain isn't available because someone has something that prevents it
>> being registered", and "this domain isn't available to anyone for
>> policy reasons." Consider people doing compliance checks, who maybe
>> shouldn't have access to the SRS directly and who should only have
>> access to the RDDS. They still need to be able to see these
>> distinctions.
>>
>> A
>>
>> --
>> Andrew Sullivan
>> [email protected]
>>
>> _______________________________________________
>> regext mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/regext
>>
>>
>> _______________________________________________
>> regext mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/regext
>
>
> —
> Francisco Obispo
> Uniregistry Inc.
> _______________________________________________
> regext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/regext
—
Francisco Obispo
Uniregistry Inc.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
