<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.5pt;
        font-family:Consolas;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:Consolas;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:123812099;
        mso-list-type:hybrid;
        mso-list-template-ids:1146629870 1972418946 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-number-format:roman-lower;
        mso-level-text:"\(%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:1.0in;
        text-indent:-.5in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoPlainText>Ok. This is what I read into what was stated; hopefully the
meaning is true.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>For reasons unstated, the spec will state <o:p></o:p></p>

<p class=MsoPlainText style='margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText style='margin-left:1.0in;text-indent:-.5in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>(i)<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>how conforming systems shall handle a particular subset
of i-name name-forms, and <o:p></o:p></p>

<p class=MsoPlainText style='margin-left:1.0in'><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText style='margin-left:.5in'>(ii) shall define how conforming
systems shall behave when interacting with one specific (commercial) provider
of proxied, XRI name resolution services.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>The spec will offer non-standardized and non-normative recommendations
on using OpenID protocols for names and name resolution procedures other than
the above.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>Now, I don&#8217;t like some of the implications in that storyline.
But let's leave that opinion aside, in favor of what's good about it:-<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText style='margin-left:.5in'>a. OpenID1.x gave one persistent
Identities for user to supply as User-Supplied Identifies; one leveraged the
delegated authentication to obtain provider portability.<o:p></o:p></p>

<p class=MsoPlainText style='margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText style='margin-left:.5in'>b. OpenID2.0 gives one an
XRDS-based version of the same. OpenID2.0 gives one a little more in the
feature arena, in that multiple providers can be nominated as legitimate
asserting parties.<o:p></o:p></p>

<p class=MsoPlainText style='margin-left:.5in'><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText style='margin-left:.5in'>c. OpenID2.0 gives one what XRIs
have to offer - above and beyond the above benefits of URIs - packaged in a clever
manner that makes their handling rather similar to handling URI Identifiers.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>The part of the good stuff that doesn&#8217;t hold for me
is (c), given (i) and (ii) above. The part of XRIs are interesting (group entitlement
for example) beyond URIs seem to be being given short shrift by the policies of
(i) and (ii).<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>XRIs come with a certain &#8220;user-acceptance baggage&#8221;,
compared to URIs. If we now deny XRIs those very properties that can distinguish
them from the limits faced by URIs, sure we biasing XRI non-acceptance, given
the unlevel playing field the face against when competing with the more
accepted, easier to use, URIs?<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>-----Original Message-----<br>
From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf
Of Recordon, David<br>
Sent: Sunday, July 08, 2007 12:20 PM<br>
To: Martin Atkins; general@openid.net<br>
Subject: Re: [OpenID] Recycling OpenIDs (Was: What's broken in OpenID 2.0?(IIW
session))</p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>Realizing I'm jumping in late, though I'd have to agree
with Mart here.<o:p></o:p></p>

<p class=MsoPlainText>For a while I've felt strongly that the OpenID spec
around discovery<o:p></o:p></p>

<p class=MsoPlainText>should only describe what to do with = and @ i-names and
recommending<o:p></o:p></p>

<p class=MsoPlainText>use of the proxy resolver.&nbsp; Then saying that if a RP
wants to accept<o:p></o:p></p>

<p class=MsoPlainText>other forms of an XRI it needs to figure out how to do so
on its own.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>--David<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>-----Original Message-----<o:p></o:p></p>

<p class=MsoPlainText>From: general-bounces@openid.net
[mailto:general-bounces@openid.net] On<o:p></o:p></p>

<p class=MsoPlainText>Behalf Of Martin Atkins<o:p></o:p></p>

<p class=MsoPlainText>Sent: Monday, June 11, 2007 4:21 AM<o:p></o:p></p>

<p class=MsoPlainText>To: general@openid.net<o:p></o:p></p>

<p class=MsoPlainText>Subject: Re: [OpenID] Recycling OpenIDs (Was: What's
broken in OpenID<o:p></o:p></p>

<p class=MsoPlainText>2.0? (IIW session))<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>Peter Williams wrote:<o:p></o:p></p>

<p class=MsoPlainText>&gt;&nbsp; <o:p></o:p></p>

<p class=MsoPlainText>&gt;&nbsp; Only control of the unique inumber (which
could <o:p></o:p></p>

<p class=MsoPlainText>&gt;&gt; be based on Freenet DHTs as easily as on DNS)
offers the <o:p></o:p></p>

<p class=MsoPlainText>&gt;&gt; non-subvertible persistent identity desired by
anyone seeking <o:p></o:p></p>

<p class=MsoPlainText>&gt;&gt; complete freedom from authority.<o:p></o:p></p>

<p class=MsoPlainText>&gt; <o:p></o:p></p>

<p class=MsoPlainText>&gt; This is what I just cannot get my head around - on
what the mainline<o:p></o:p></p>

<p class=MsoPlainText>&gt; OpenId community is actually doing! XRI can mean so
many things,<o:p></o:p></p>

<p class=MsoPlainText>&gt; depending on the management model one applies to its
generic<o:p></o:p></p>

<p class=MsoPlainText>framework.<o:p></o:p></p>

<p class=MsoPlainText>&gt; The above is one extreme, whose existance is
important (if rarely<o:p></o:p></p>

<p class=MsoPlainText>&gt; actually leveraged) when seeking mass adoption.<o:p></o:p></p>

<p class=MsoPlainText>&gt; <o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>I'm gravely concerned by several recent messages that
have said things <o:p></o:p></p>

<p class=MsoPlainText>along the lines of &quot;Problem X is not a problem
because XRI <o:p></o:p></p>

<p class=MsoPlainText>infrastructure can *theoretically* do Y.&quot;<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>I can only get behind XRI being in the OpenID 2.0 spec
if:<o:p></o:p></p>

<p class=MsoPlainText>&nbsp; * A particular, interoperable protocol or set of
protocols is called <o:p></o:p></p>

<p class=MsoPlainText>out and described completely.<o:p></o:p></p>

<p class=MsoPlainText>&nbsp; * The whole end-to-end resolution process mapping
a defined set of <o:p></o:p></p>

<p class=MsoPlainText>XRIs that are allowed when using OpenID to a particular
XRDs document is<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>written down clearly somewhere in a manner that is
suitable for OpenID <o:p></o:p></p>

<p class=MsoPlainText>developers that have no interest in the rest of the XRI
infrastructure.<o:p></o:p></p>

<p class=MsoPlainText>&nbsp; * The implementation of the above does not place
an excessive burden <o:p></o:p></p>

<p class=MsoPlainText>on RP developers above and beyond what they have to
include to support <o:p></o:p></p>

<p class=MsoPlainText>HTTP URLs.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>I was starting to warm to the idea of supporting i-names
on the basis <o:p></o:p></p>

<p class=MsoPlainText>that they are well defined, reasonably well-understood
and they can be <o:p></o:p></p>

<p class=MsoPlainText>supported with minimal burden through the use of a proxy
resolver. <o:p></o:p></p>

<p class=MsoPlainText>However, if that same mechanism cannot be applied to
these <o:p></o:p></p>

<p class=MsoPlainText>&quot;peer-to-peer&quot; XRIs or XRIs from alternative roots
then I don't believe <o:p></o:p></p>

<p class=MsoPlainText>that they can reasonably be included in the OpenID 2.0
specification. <o:p></o:p></p>

<p class=MsoPlainText>OpenID developers should not have to jump through hoops
to implement a <o:p></o:p></p>

<p class=MsoPlainText>protocol that has little adoption thus far and has yet to
prove itself.<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>(As usual, I'm speaking only for myself here.)<o:p></o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText><o:p>&nbsp;</o:p></p>

<p class=MsoPlainText>_______________________________________________<o:p></o:p></p>

<p class=MsoPlainText>general mailing list<o:p></o:p></p>

<p class=MsoPlainText>general@openid.net<o:p></o:p></p>

<p class=MsoPlainText>http://openid.net/mailman/listinfo/general<o:p></o:p></p>

<p class=MsoPlainText>_______________________________________________<o:p></o:p></p>

<p class=MsoPlainText>general mailing list<o:p></o:p></p>

<p class=MsoPlainText>general@openid.net<o:p></o:p></p>

<p class=MsoPlainText>http://openid.net/mailman/listinfo/general<o:p></o:p></p>

</div>

</body>

</html>