+1 to Martin's point.<div><br></div><div>To respond to Shane: one of the hardest elements of technology development is consistent implementation and adoption of protocols and formats.</div><div><br></div><div>The more complicated you make technology, the more likely you'll get deviating (and therefore non-interoperable) implementations.</div>
<div><br></div><div>If you want to know why SREG has been adopted to date, it's because it's simple and EXTREMELY limited. In other words, it's hard to eff up.</div><div><br></div><div>You start extending it -- even by one element -- you've increased complexity and barriers to entry.</div>
<div><br></div><div>I suggest that you invest heavily in Attribute Exchange, in all the custom attributes you want, and leave SREG behind. If you can push adoption and use of AX, you can create whatever custom schema you like. There's no guarantee, of course, that anyone else will support the brilliant schema that you come up with, but at least you'll be intellectually satisfied.</div>
<div><br></div><div>This is largely the origin of the Portable Contacts schema and protocol (<a href="http://portablecontacts.net">http://portablecontacts.net</a>), which I hope ends up being expressed using AX. We don't need more schema -- we need more adoption:</div>
<div><br></div><div><a href="http://factoryjoe.com/blog/2008/06/04/inventing-contact-schemas-for-fun-and-">http://factoryjoe.com/blog/2008/06/04/inventing-contact-schemas-for-fun-and-</a> profit-ugh<br><br></div><div>Chris</div>
<div><br><div class="gmail_quote">On Mon, Dec 1, 2008 at 4:07 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Shane B Weeden wrote:<br>
><br>
> Andrew - understand your points, but that can be argued both ways. If I<br>
> *want* to use SREG, and *want* to advertise my headphone preference and<br>
> cannot extend the spec, I am forced to overload an existing attribute<br>
> name rather than advertise a more meaningful alternative. This is<br>
> exactly what happened in many early deployments of LDAP. And you're<br>
> right - no one will care that my implementation doesn't enforce that<br>
> element of the spec, and it won't. It's a shame though that some others<br>
> might, when that could simply be a deployment-time decision.<br>
><br>
<br>
</div>Just to complete this thought, what would be the reason not to use AX<br>
for this use-case? (of avertising your "headphone preference")<br>
<br>
It seems to me that whether you add an additional attribute to SREG or<br>
encode it using the designed-in extensibility of AX you need to alter<br>
both the Consumer and Server to support that attribute anyway, so at<br>
that point you can alter Consumer and Server to use AX at the same time.<br>
<br>
Since AX is has decentralized extensibility designed in, I'm still<br>
wondering what the motivation is to allow ad-hoc extensibility in SREG.<br>
What use-cases does an ad-hoc SREG extension attribute satisfy that a<br>
custom AX attribute does not?<br>
<br>
(The sort of use-case I'm looking for is something like "I want to<br>
automatically discover the headphone preference of the user."; "I want<br>
to send custom attributes using SREG" is not really a use-case, it's one<br>
of a number of solutions that satisfy the use-case.)<br>
<br>
_______________________________________________<br>
<div><div></div><div class="Wj3C7c">general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Citizen-Participant &<br> Open Technology Advocate-at-Large<br><a href="http://factoryjoe.com">factoryjoe.com</a> # <a href="http://diso-project.org">diso-project.org</a><br>
<a href="http://citizenagency.com">citizenagency.com</a> # <a href="http://vidoop.com">vidoop.com</a><br>This email is: [ ] bloggable [X] ask first [ ] private<br>
</div>