No subject

&gt; Disallowing post responses limits the use of the more verbose<br>
&gt; extensions (e.g. attribute exchange). =A0While this might be acceptabl=
e<br>
&gt; for Luke&#39;s particular use case, it might leave it unsolved for oth=
ers.<br>
<br></div>
The POST response is a good point and clearly a valid use case, and I think=
 it=92s supported no matter what we decide to do. It=92s possible to build =
a receiver that handles POST params if they are present, but otherwise serv=
es up the correct cache headers and Javascript to handle the GET. That woul=
d provide a performance boost in the common case, while still being fully c=
ompatible with the spec.</span></font></div>
</blockquote><div><br>I would add that, in the case of checkid_immediate, i=
t is not advisable to have many extensions. Each request to release an attr=
ibute increases the odds that the user will need to be prompted to approve =
the request, and therefore decreases the chance of success of a checkid_imm=
ediate request.<br>
<br>As Luke pointed out, checkid_immediate stands to gain most from the lat=
ency improvements.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"b=
order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin=
g-left: 1ex;">
<div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-=
size: 11pt;"><br>
<br>