Re: [XRI] TAG recommendation

Hello John,

John Bradley wrote:
> Thanks Stuart,
>
> The TAGs position seems clear and categorical from my position on the 
> outside.
> Without clear guidelines on how to reach the bar that the W3C has 
> set,  it would seem unlikely the XRI or anyone else will reach it.
> It has been stated that existing schemes don't meet the new standards.
Guidelines for new URI scheme registrations can be found in RFC 4395 - 
section 5 details the registration process. Governance is via the IETF 
and at best the TAG and more generally  W3C have influence but no control.

[1] http://www.rfc-editor.org/rfc/rfc4395.txt
> I don't know that it is productive for us to start digging into where 
> that bar is if we can find a way of implementing XRI without a new 
> scheme.
>
> If people want to start a tread on what standard must be met to 
> justify an new scheme,  you know where to find me:)
>
> Setting the scheme issue aside for the moment.
ok.

> That gives us a couple of other topics we can try to put to rest 
> before the TAG meeting.
>
> A question on your first point.
>
> Is there some thought that only URLs should be used as user 
> identifiers for application purposes?
I'd described it as a pro-URI bias - that shouldn't be a surprise. I 
also scoped my comment in terms of languge/format definitons - rather 
than UI artefacts and login forms.

Lets say, that my email address, skw@hp.com is used as a user identifier 
for me in some system.

I could define a userId element in some new format and say that its 
content must be an email address thus:

    <userID>skw@hp.com</userID>

or I could leave the definition in the format spec more open and say 
that element content must be a URI

    <userID>mailto:skw@hp.com</userID>

I believe that the TAG bias is toward the latter.
> If I want to log into a application what identifiers are Good vs Bad?
>
> 1. jbradley
> 2. jbradley@wingaa.com
> 3. =jbradley
> 4. xri://=jbradley
> 5. http://xri.net/=jbradley
> 6. =!BF81.FD97.C81B.B4E5
> 7. thread-safe.net
> 8. http://thread-safe.net
> 9. VE7JTB
> 10. 703-650-0389
>
> These are all identifiers that I use to gain accesses to resources.  
> Is there a desire to restrict the acceptable form of input for an openID?
I guess that was the question I was asking you... is there a desire to 
promote the i-name/i-number based identifiers in formats to the 
exclusion of equivalent URI forms. Requiring folks to have to 
purchase/rent an i-name (at $12 per personal -name per yeat [2]) to use, 
say Oauth or OpenID [and I am not saying that *is* the case, but I 
believe that that peception exists] would be unaccceptable to many. 
FWIW, and I'm sure that you can correct me, I expect that the relevant 
specs.will allow more general URI forms of identifier, and may even 
require URI forms of XRI in fields that are exchanged 'on the wire'.

[2] http://2idi.com/register

To answer your question above: wrt to a closed system without shared 
identities then whatever you like. Where identities are shared, the 
identity components in message that cross the wire should all be URIs.

> If we don't use a URI scheme then obviously the xri:// form that is 
> currently valid would need to be deprecated.
The above is orthogonal to the scheme question =jbradley is not a URI.
> If I enter =jbradley into an openID RP and the RP normalizes  that to 
> http://xri.net/=jbradley in the same way that if I enter 
> thread-safe.net it will normalize that to http://thread-safe.net,  is 
> that a problem?
RP??

I think so, certainly I wouldn't have problem with that - and I wouldn't 
have a problem with xri://=jbradley either were it successfull 
registered as a xri: scheme or were it generally acceptable as a URI 
scheme and on track for registration (which I know was an intent that we 
may have disrupted).

> If  OpenID were to adopt CURIE as you suggest, then if we define:
> xmlns:xri="http://xri.net/"
>
> That would allow a identifier such as  xri:=jbradley to be entered and 
> become http://xri.net/=jbradley  ?
Again, I was not talking in terms of what a user enters in a UI, but 
what crosses the wire on a message.

UI Fields -> URI -> full or abbreviated URI in a message. I was offering 
CURIEs as an abbreviation mechanism that could be adopted in message 
formats, though equally (IMO) base+rel URI will also serve in many cases.
>
> I am new to CURIE so the answer is probably obvious to others.
>
> If that is the idea then perhaps CURIE is an option.
I only mention them because, at least in the hypertext community there 
is a lot of negative reaction at the prospect of authors having to 
correctly and repeadly write lengthy URI that differ only in a few 
trailling characters... CURIEs is an approach to addressing that problem 
from the hypertext community.

I would not expect end users typing credentials into a login form to 
have to care or be aware of it.
> On your second question:
>
> In native XRI resolution a XRDS document is always returned,  so I 
> don't think that is a problem.
Well... the question is: too what do the i-name "=jbradley" or the URI 
"http://xri.net/=jbradley" and xri://=jbradley refer. Do they refer to 
you (a person) or some metadata (about you).

If I want to say, say in RDF, who created the thing referred to by the 
two URI above?

    Your parents?
    The author of a metadata document (probably you)?

The answer you give above suggests that that the identifiers refer to an 
XRDS document and not a person.

How about of you were to mint an XRI identifier for say the XRI 2.0 
resolution spec (there may be one I guess)

http://xri.net/@oasis*specs*os*xri($v2.0)*resolution   (please look past 
any clumsy syntactic mistakes - I hope the intent of the identifier is 
clear).

Does that identifier (assuming that the intent was that it refer to the 
XRI 2.0 resolution spec) in fact (in this fiction) do so?

Would a retrieval using that identifier expect to obtain a copy of the 
specification or an XRDS document? If the answer to that question is, 
that depends on the Accept: header, then that is counter to web 
architecture. If the answer, which I think you give above, is that you 
always get back a representation of an XRDS document, then despite the 
intent the identifier does not infact refer to the spec it was intended 
to reference.

An alternative way of asking the same question: If, say in RDF, I were 
to want to speak separately of the spec and the XRDS document how would 
I make distinct references.

> The HXRI proxy server has a number of input parameters to facilitate 
> backwards compatibility with browsers and other software that is not 
> XRI aware.
> You should refer to XRI 2.0  Resolution  Sec 11.5.  This deals with 
> the values passed in the http(s) Accept headers sent to a HXRI proxy
>
> Lets consider my XRI =jbradley largely because I may be the only 
> person using accept headers in my actual XRDS.
> You may want to skip to the end of the XRDS my examples will refer 
> back to the individual SEPs
>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <XRDS ref="xri://=jbradley" xmlns="xri://$xrds">
>>  <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)">
>>   <Query>*jbradley</Query>
>>   <Status ceid="off" cid="verified" code="100"/>
>>   <ServerStatus code="100"/>
>>   <Expires>2008-07-19T01:24:34.000Z</Expires>
>>   <ProviderID>xri://=</ProviderID>
>>   <LocalID>!bf81.fd97.c81b.b4e5</LocalID>
>>   <CanonicalID>=!BF81.FD97.C81B.B4E5</CanonicalID>
>>   <Service priority="10">
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type match="null"/>
>>    <Path match="null"/>
>>    <MediaType select="true">application/rdf+xml</MediaType>
>>    <URI append="none" 
>> priority="1">http://thread-safe.net/data/foaf</URI>
>>   </Service>
>>   <Service priority="10">
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type>
>>    <Type match="null" select="false"/>
>>    <Path match="default"/>
>>    <Path match="null"/>
>>    <Path>(+contact)</Path>
>>    <URI append="qxri" 
>> priority="1">http://ipage2.ezibroker.net/ipage/ipage.faces?iname=</URI>
>>   </Service>
>>   <Service priority="10">
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type select="true">xri://$res*auth*($v*2.0)</Type>
>>    <MediaType>application/xrds+xml;trust=none</MediaType>
>>    <URI 
>> priority="10">http://resolve.ezibroker.net/resolve/=ve7jtb/</URI>
>>   </Service>
>>   <Service priority="10">
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type match="null"/>
>>    <Path match="null"/>
>>    <MediaType select="true">application/rss+xml</MediaType>
>>    <URI append="none" 
>> priority="1">http://feeds.feedburner.com/Thread-Safe</URI>
>>   </Service>
>>   <Service priority="1">
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type match="null" select="false"/>
>>    <Type select="true">xri://+i-service*(+xmpp)*($v*1.0)</Type>
>>    <Path>(+chat:jabber)</Path>
>>    <Path>(+chat:xmpp)</Path>
>>    <URI append="none" priority="1">jabber://jbradley@wingaa.com</URI>
>>   </Service>
>>   <Service priority="10">
>>    <Type>$context</Type>
>>    <Type select="true">($context)*($ldap)</Type>
>>    <Path select="true">($context)*($ldap)</Path>
>>   </Service>
>>   <Service priority="1">
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type select="true">xri://+i-service*(+forwarding)*($v*1.0)</Type>
>>    <Type match="null" select="false"/>
>>    <Path>(+index)</Path>
>>    <URI append="qxri" 
>> priority="1">http://linksafe-forward.ezibroker.net/forwarding/</URI>
>>   </Service>
>>   <Service>
>>    <ProviderID>xri://!!1003!103</ProviderID>
>>    <Type select="true">http://openid.net/signon/1.0</Type>
>>    <URI append="none" 
>> priority="1">https://linksafe.ezibroker.net/server/</URI>
>>    <openid:Delegate 
>> xmlns:openid="http://openid.net/xmlns/1.0">=ve7jtb</openid:Delegate>
>>   </Service>
>>  </XRD>
>> </XRDS>
>>
>
> http://beta.xri.net/=jbradley  Because the XRI path is empty this will 
> match my contact SEP.  The SEP contains a single URL element.
> The proxy resolver makes the assumption that because the XRDS content 
> type was not requested in the query it should issue a redirect to the 
> URL.
>
> If you type it into a browser you are redirected to may contact page.  
> (its a opensocial container under development just so you know not to 
> expect something beautiful)
:-)
> If a RSS reader access the same HXRI it should do so with an accept 
> header of application/rss+xml this will cause the RSS sep to be 
> selected and a redirect to my RSS feed will be returned to the 
> requesting application.
>
> The HXRI encodes the accept header as the _xrd_m query parameter.  
> This can be overridden by including _xrd_m as part of the query string 
> for the HXRI.
>
> http://beta.xri.net/=jbradley?query&_xrd_m=application/rss+xml  this 
> gets you redirected to my RSS feed at feed burner.
>
> Use beta.xri.net for testing accept header behavior in HXRI,  there 
> are still some code things we are testing before rolling this out on 
> the main xri.net HXRI proxy.
>
> If an XRI aware application wants to use a HXRI it can include a 
> number of query parameters to control the proxy behavior.
>
> http://beta.xri.net/=jbradley?query&_xrd_r=application/xrds+xml  
> returns the XRDS document for =jbradley
>
> http://beta.xri.net/=jbradley?query&_xrd_m=application/rss+xml&_xrd_r=application/xrd+xml&sep=true&https=true 
>
>
> This preforms service selection based on the application/rss+xm media 
> type and returns a XRD document containing the selected Service 
> endpoint, and forces all resolution to be preformed over https.
>
> It is documented in exhaustive detail in the XRI 2.0 resolution spec.
>
> If there is a problem with how we are using accept headers then lets 
> sort it out.
It will take me more time to internalise what's going on in the specs - 
its useful to have a handy guide that knows them well - thanks.

I hope the questions I ask above ([document] or [metadata document about 
[document]]) help you understand where I and the TAG are commng from on 
that topic.

IIUC'ish the use of HTTP as an underlying mechanism for resolving an XRI 
generates a bunch of URI that (as it happens) embed accept headers in 
the URI making for distinct URI for referenced  'thing' and metadata 
about referenced 'thing'.

Anyway, lets sort out whether there is really a problem there that needs 
to be address.

> Regards
> John Bradley
> OASIS IDTRUST-SC
> http://xri.net/=jbradley
> 五里霧中

Stuart
--

Received on Saturday, 19 July 2008 10:55:21 UTC