Replies inline...<br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 10:03 PM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div>I am referring to identifier abstraction to make certain that we clearly understand the need for a primary key vs a display identifier.</div><div></div></div></blockquote><div><br>+1. This is a very valid issue. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><br></div><div>We ran into this with XRI and the presumption that the claimed_id is what is displayed for the user.</div>
<div><br></div><div>With XMPP identifiers you may have multiple identifiers that resolve to the same XRD and hence have the same claimed_id but may want your input identifier represented in some way.</div><div><br></div><div>
Perhaps we need more that one identifier at the API layer.</div><div></div></div></blockquote><div><br>+1. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><br></div><div>What I am saying is that if the core spec assumes URI then there will be a built in bias as there is now.</div><div></div></div></blockquote><div><br>Wondering _how_ you would describe an OpenID Identifier if it's not a URI...would you specify string-text (with x,y, z, etc as allowed characters)? Or anything goes?<br>
<br>The only reason I ask is that is seems most Identifiers (in the generic sense) are URI's with a scheme: (http://; xri://; ldap://; mailto:; uri://; etc).<br><br>Are JID's not URI's?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div></div><div>We need to consider how provider portability could be achieved or at-least not be precluded by core design choices.</div><div></div></div></blockquote><div><br>+1<br><br> </div></div><br>