OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Minutes: XRI TC Telecon 8-9AM PT Thursday 2008-08-21


Drummond wrote:

> We summarized the four main "legs" of the argument for the XRI layer of
abstract 
> identification:

> 1) Separation of abstract from concrete identifiers for purposes such as
persistence, 
> descriptor management, and synonym management.
> 2) Cross-references - the ability to reuse identifiers across contexts.
> 3) Global context symbols - the ability to share contexts across contexts.
> 4) Uniform discovery - the (growing) feature set of XRDS documents.

I still believe that this argument is missing one of the most important
differences 
which is that XML Resolution provides a fundamentally different entity model
than that of HTTP resources. (This is where Roy Fielding has got it wrong in

the case of XRI, because he believes that that XRI/URI share the same entity
space. 
They do not.)

Here's a quick survey of some of the differencees.

In the URI/HTTP model, the entity (the HTTP resource) is directly accessable
by the (HTTP) framework. In XRI Resoution, the entity (the XRI authority)
lives 
only abstractly -- the XRI protocol does not support direct access but
instead 
supports only metadata discovery. (As we all know, the metadata descriptor
is 
designed to describe the abstract XRI entity primarily in terms of "service 
endpoints". This service endpoint metadata orientation is itself a novel 
distinction, and I'm a bit surprised that the TC does not appreciate the
value
of this distinction.)

In the URI/HTTP model, there is, to date, no formalized metadata discovery 
protocol -- at least not one that is sanctioned by the W3C and in wide use.

The XRI Resolution model supports the notion of absolute identity of its 
entities. For example, an entity can be referenced by synonymous 
identifiers (incuding polyarchical synonyms) and the framework formalizes
the secure mapping of these identifiers to entities. URI/HTTP has no
such formalization of mapping synonymous identifiers to (absolute) entities.

---

In conclusion, the fundamental difference between the URI/HTTP
entity model and the XRI Resolution entity model (outlined above) 
is just as important as the argument that XRI syntax supports cross-refs, 
persistence, and the like. 

~ Steve

PS: Trying to use an XRDS to describe metadata in the URI/HTTP resource
entity model is not a good idea. I won't go into details on this, because
I've already outlined the differences in entity models above. Before 
attempting to morph a descriptor of one entity type into a descriptor of 
a fundamemtally different entity type, one should clearly understand the
differences between the entity models -- and then ask the question, "what 
benefit do we get from doing that?" 

_____________________________________________
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Thursday, August 21, 2008 2:02 PM
To: 'OASIS XRI TC'
Cc: 'Peter Davis'; 'John Bradley'
Subject: [xri] Minutes: XRI TC Telecon 8-9AM PT Thursday 2008-08-21

Following are the minutes the unofficial telecon of the XRI TC at:

Date:  Thursday, 21 August 2008 USA
Time:  8:00AM - 9:00PM Pacific Time

ATTENDING

John Bradley
Nat Sakimura
Nika Jones
Drummond Reed

REGRETS
Peter Davis (vacation)
Marty Schleiff


AGENDA

1) MIXI

Nat explained that Mixi, the largest SNS in Japan with about 15M users, has
adopted OpenID and is using it in an innovative way in that they are
providing OpenID identifiers in OpenID message responses that can not only
be used to authenticate a Mixi member, but to prove that one Mixi user is a
friend of another Mixi user. See the writeup on Nat's blog at:

	http://www.sakimura.org/en/ 

Nat explained that Mixi's use of OpenID is still early and does not yet
support XRI, though their syntax for internationalized identifiers is
similar. Nat said that he has found that there is consensus that if you dive
deeply into OpenID, using an http: based OpenID has many problems, such as
those illustrated in the paper we gave at the IDtrust Symposium last
February:

	
Http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds.
pdf

John has also found in OSIS OpenID testing that of all the OpenID providers
(OPs) he has tested, only one currently implements the recommended policy of
automatically redirectly http: URIs to https: URIs. Nat said Mixi does the
same thing; in this case it would be the second.


2) W3C TAG DISCUSSION

Although Peter was not able to attend this meeting, he, Drummond, and John
have a call with the W3C TAG leadership tomorrow to discuss next steps.

	http://lists.w3.org/Archives/Public/www-tag/

Drummond posted a message to the XRI TC list last week regarding one
specific topic - URN requirements - but there was not time left on the
agenda to discuss it. However we discussed it briefly on this call and
agreed it should be posted to the TAG list before tomorrow's call.

# DRUMMOND to post the URN requirement email to the TAG list.

Drummond also said that there have been off-list communications from
observers of the TAG discussion regarding the strong need for abstract
identifiers vs. concrete "locators".

We summarized the four main "legs" of the argument for the XRI layer of
abstract identification:

	1) Separation of abstract from concrete identifiers for purposes
such as persistence, descriptor management, and synonym management.
	2) Cross-references - the ability to reuse identifiers across
contexts.
	3) Global context symbols - the ability to share contexts across
contexts.
	4) Uniform discovery - the (growing) feature set of XRDS documents.

We then discussed the specific topics/questions that we should propose
pursuing with the TAG (not necessarily in this order):

	1) XRDS: Determine the TAG's input on XRDS and http-based XRDS
discovery and discuss if this can be "carved out" for continued work.
	2) http: subschemes:  Arrive at a conclusion about standardization
of http: subschemes to do URI-scheme-to-http-scheme mappings. Should that be
W3C work or XRI TC work? 
	3) xri: scheme: Should we apply for a provisional xri: scheme while
this discussion is ongoing, because this is the proper approach (as we have
now been educated)?
	4) IRI and URI compatability: close the misunderstanding about
improper use of symbols in an XRI when it is used as a URI - clarify that we
are using the URI spec properly (the regname rule).

# DRUMMOND to write this up and send to the attendees for tomorrow's call.

# DRUMMOND to send a report on tomorrow's call to the TC list.
 << File: ATT00125.txt >> 

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]