[OpenID board] May 19, 2010 OpenID Board Meeting Minutes

Dick Hardt dick.hardt at gmail.com
Tue Jun 1 05:25:15 UTC 2010


Hi Nat, if you want to continue this, let's do it on specs. This list is not the right one for the technical discussion.

On 2010-05-31, at 9:52 PM, Nat Sakimura wrote:

> Here is the XRI canonicalizer for PHP.
> 
> <?php
>  $openid = $_POST['openid'];
>  if(preg_match('/^[=@+$!\(]/',$openid)){
>  	$url = 'http://xri.net/' . $openid;
>  } elseif(preg_match('/^xri:\/\//',$openid) {
> 	$url = preg_replace('/^xri:\/\//','http://xri.net/',$openid);
>  }
> ?>
> 
> Rest is the same as normal URL Claimed ID.
> I have never seen somebody use xri://=nat kind of sintax, so the last
> 3 lines can be deleted.
> Then, it is just one liner.
> 
> Is it complex? I do not think so.
> 
> =nat
> 
> On Tue, Jun 1, 2010 at 11:39 AM, Dick Hardt <dick.hardt at gmail.com> wrote:
>> 
>> On 2010-05-31, at 7:34 PM, Chris Messina wrote:
>> 
>>> At the very least, the 2.x series of changes should investigate the net-net adoption of all of the features of OpenID and prioritize and de-prioritize accordingly.
>>> 
>>> Supporting XRIs have been reported to add complexity to the discovery code, and further, seem to have little adoption in the mainstream and few implementations in the wild. I'd be eager to hear specific stats that contradict that sentiment, but I don't want to hold on to features purely out of nostalgia.
>>> 
>>> This points to yet another reason why I worry about the v.Next naming: if we can't even cut, cut, cut from the 2.0 spec to create a leaner, simpler protocol that's easier to implement and support, I have a hard time imagining how we're going to arrive at a simpler, stream-lined technology when v.Next sounds like it's chartered to include everything and the kitchen sink.
>> 
>> time will tell :)
>> 
>>> 
>>> Perhaps along with the MRD/PRD that Brian Kissel wants, we should also produce a DRD — a developer requirements document — that provides insight into which features of OpenID have actually been implemented by the most successful OPs (based on market adoption and usage). That is, in order to be taken into consideration for this requirements document, you have to have already deployed a public OpenID Provider and have people using it.
>> 
>> Good idea -- but I think you mean implementor not developer here.
>> 
>> 
>> _______________________________________________
>> board mailing list
>> board at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-board
>> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
> _______________________________________________
> board mailing list
> board at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-board



More information about the board mailing list