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

["Steven Churchill" <steven.churchill@xdi.org>]

Drummond,

Good discussion, and you make excellent points in the comparison you sent to
the W3C TAG list.

Regarding your points below, indeed, in the XRI entity model (which is
hierarchical) each arc between two entities has associated with it metadata
(in the form of an XRDS) and this visual picture is really cool,  because it
calls out the fact that in XRI resolution the parent entity is authorative
for the metadata describing the child entity. 

You also correctly point our that the XRDS (that thing that describes the
abstract entity in the XRI entity model) can itself be represented as an
entity in the URI/HTTP entity model (the WWW perspective.) This is where I
get a bit uncomfortable, though, because the most important "distinction"
(the XRI value add, so to speak) is not about the metadata
descriptor-rather, it is about the new XRI abstract entity model itself. Put
another way, it is not that important that the entity metadata descriptors
of the XRI entity space can be treated as entities themselves in the
URI/HTTP entity space. What is more important I think is that XRI resolution
introduces a new abstract (non-concrete) entity model-and that the features
of that entity model (abstract entities defined in terms of service
endpoints, secure mapping from synonymous identifiers to absolute entity,
etc)-are unique and valuable features, not available in the URI/HTTP entity
model. 

~ Steve

_____________________________________________
From: Drummond Reed
Sent: Thursday, August 21, 2008 10:40 PM
To: 'Steven Churchill'; 'OASIS XRI TC'
Cc: 'Peter Davis'; 'John Bradley'
Subject: RE: [xri] Minutes: XRI TC Telecon 8-9AM PT Thursday 2008-08-21

Steve,

I agree your argument is a strong one and it is part of what we included in
bucket (1) even if we did not articulate it well. I myself think I'm coming
to a greater appreciation of that argument after writing up the comparison
between XRIs /XRDS documents and URNs/URCs that I sent to the W3C TAG list
today:

	http://lists.w3.org/Archives/Public/www-tag/2008Aug/0107.html

I'm realizing for the first time what I think you are saying below: that
from the WWW perspective, XRI infrastructure actually defines a class of
resources - XRDS documents - that are first-class resources in the WWW
architecture sense (because they all XML documents with http/https URIs),
but which are NOT the resources identified by XRIs. Instead they are only
containers of the pointers - service endpoint URIs - that ultimately
identify (in different contexts) the target resource identified by the XRI.

Because I've so long considered an XRDS document to be simply a descriptor -
a representation of the identifier "arc" that is the XRI - I've never
thought of it as a first-class node in the graph of resources. However
that's only true when you look at it from the perspective of the XRI graph
of _abstract_ resources. When you look at it from the perspective of
concrete WWW resources, then an XRDS document IS a node in the graph.

That means what I've always thought of from the abstract XRI perspective
as...

	XRI arc -------> XRDS descriptor of the arc ------> target resource
node

...can be thought of from the concrete WWW URI perspective as...

	XRI arc -------> XRDS descriptor node ------> service endpoint URI
arc(s) ------> target resource node

Do I have this right? Is that what you mean by "XML resolution defines a
different entity model than HTTP resources"?

=Drummond 

_____________________________________________
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Thursday, August 21, 2008 5:40 PM
To: 'Drummond Reed'; 'OASIS XRI TC'
Cc: 'Peter Davis'; 'John Bradley'
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>>