<font color='black' size='2' face='arial'>Really? You would elevate these purported benefits to the same level of importance as authenticated (or "differentiated") access? My take on these purported benefits is:
<div><br>
</div>
<div>1. Internationalization? Ok, this is a stretch, but I'll give it to you. But it's not like internationalized characters are disallowed by whois. </div>
<div><span style="font-size: 10pt;">See, for example: </span><span style="font-size: 10pt;">whois -h whois.nic.xn--cg4bki nic.xn--cg4bki There are others.</span></div>
<div class="p1"><span class="s1"><br>
</span></div>
<div>2. Standardized query/response/errrors? Again, a stretch. 301, 302, 404, 429... big deal. Anyway, AWIP and CNRA have tried to do the first two.</div>
<div><br>
</div>
<div>3. Ahem... extensibility? Really? Anyone wishing to support anything beyond the profile must undergo the dreaded RSEP, effectively muting this benefit. </div>
<div><br>
</div>
<div>4. HTTPS? That's more important than authenticated/differentiated access? Who is clamoring for this? Nobody!</div>
<div><br>
</div>
<div>5. Standardized bootstrapping? New gTLDs must all support whois.nic.<tld></div>
<div><br>
</div>
<div>6. Standardized redirection for thin? There are three thin registries: com, net, tv. All provide the reference to registrar with the same key "whois server:"</div>
<div><br>
</div>
<div>7. Flexibility to support various policies? Okay, maybe someone at ICANN cares a lot about this, but few in the community care, especially given #3 above. </div>
<div><br>
</div>
<div>What the community does care about is authenticated/differentiated access. <span style="font-size: 10pt;">As several have already written, RDAP without this is simply a repackaging of existing capabilities. *NONE* of the above are significant or impactful changes to existing capabilities that benefit any entity, individual or corporate. </span></div>
<div><span style="font-size: 10pt;"><br>
</span></div>
<div><span style="font-size: 10pt;">I get the impression of ICANN internal pressure to force-feed the community RDAP to meet a date, rather than a desire to put forth a noteworthy advancement in RDDS. Rather than dictate compliance with a profile that *seems* a product of ICANN's doing, rather than a grass-roots initiative, why doesn't ICANN invest effort in coordinating a solution to the obvious need for authenticated/differentiated access? And, if ICANN wishes to dictate something useful, federated authentication amongst registries would be a good start. Better yet, ICANN could be the authenticator - THAT would be useful.</span></div>
<div><span style="font-size: 10pt;"><br>
</span></div>
<div><span style="font-size: 10pt;">Ann Hammond</span></div>
<div><span style="font-family: helvetica, arial; font-size: 10pt;"><br>
</span></div>
<div><span style="font-family: helvetica, arial; font-size: 10pt;">-----Original Message-----</span>
<div>
<div>
<div>
<div>
<div style="font-family:helvetica,arial;font-size:10pt;color:black">From: Francisco Arias <francisco.arias@icann.org><br>
To: Hollenbeck, Scott <shollenbeck@verisign.com>; gtld-tech <gtld-tech@icann.org><br>
Sent: Fri, Feb 5, 2016 3:53 pm<br>
Subject: Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server Content<br>
<br>
On 2/3/16, 9:40 AM, "<a href="mailto:gtld-tech-bounces@icann.org">gtld-tech-bounces@icann.org</a> on behalf of Hollenbeck, Scott" <<a href="mailto:gtld-tech-bounces@icann.org">gtld-tech-bounces@icann.org</a> on behalf of <a href="mailto:shollenbeck@verisign.com">shollenbeck@verisign.com</a>> wrote:<br>
<br>
<br>
<br>
>As I've said before, I want to deploy RDAP in a way that addresses the issues we have with WHOIS. Functional equivalence provides no significant benefit.<br>
<br>
Just to be clear, differentiated access is not the only benefit you get from RDAP. I can think of at least the below benefits:<br>
<br>
1. Internationalization support for registration data<br>
2. Standardized query, response, and error messages<br>
3. Standardized extensibility<br>
4. Supports private access to data (i.e., over HTTPS)<br>
5. Bootstrapping mechanism to easily find the authoritative server for a given query<br>
6. Standardized redirection/reference mechanism (e.g., from a thin registry to a registrar)<br>
7. Flexibility to support various policies<br>
<br>
<br>
Regards,<br>
<br>
-- <br>
Francisco<br>
<br>
<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</font>