Gabe, good stuff, see responses inline marked
###.
=Drummond
From: Wachob, Gabe
[mailto:gwachob@visa.com]
Sent: Monday, October 31, 2005 11:54 AM
To: Drummond
Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Compromise Conceptualization
Towards CD-02
Interesting - I didn't remember that
we had defined authority. The reason I was backing away was because Dave
McAlpin asserted that the XRID was an authority. Clearly thats in conflict with
the definition here.
### I agree. The authority issues the XRID
(just like it assigns the XRI), but the XRID is not "the authority". ###
Are you suggesting that this definition
needs to be changed in any way?
Not really. I think Dave was suggesting
this though. I still suggest, as much as possible, we not talk about authority
even if we did let that definition in the syntax doc.
### Unfortunately I find discussions
around this topic are almost impossible without the term "authority".
IMHO better to have an accurate definition and use it than to try to avoid the word.
###
For what it's worth, I've had the
following conceptual model about XRIs, resources, authorities, and XRIDs:
* An XRI (Extensible Resource Identifier)
identifies a resource.
Yes, we all agree here. I hope!
### Good. ###
The *issue* is about whether the authority
segment, as separate from the path, identifies something different than the XRI
containing that authority segments plus an empty path segment.
To wit: Does @foo*bar identify something
different than the XRI xri://@foo*bar
### Did you mean not to include the
"xri://" at the start of the first XRI? Or is the difference you were
trying to get at the lack of a path? In other words, were you asking to compare
"xri://@foo*bar" and "xri://@foo*bar/"? I ask because
according to our own spec, the addition of the "xri://" means nothing,
i.e., "@foo*bar" and "xri://@foo*bar" are equivalent by
definition. So I assume what you were getting at is an empty path. See below
for more on this. ###
In the conceptual model I had been working
against, the answer is yes, because @foo*bar was identifying an authority,
which by definition is not a dog, a person, a cat or a house. This doesn't mean
that @foo*bar can't be used in a the form of a complete XRI (e.g.
xri://@foo*bar/) to identify anything (e.g. dog, person, house). It just means
that there has to be a path (perhaps empty) to suggest that the authority can
be asked about the resource identified by the *full* XRI (not just the
authority).
### I think "@foo*bar" and
"@foo*bar/" and "xri://@foo*bar" and
"xri://@foo*bar/" all identify the same resource. See below for more.
###
The reconceptualization was to say that
@foo*bar now identifies a resource that may host a authority subsegment
resolution service (perhaps) or X2R (or other services) *AND* can be a
house, dog, cat, etc. So there's a duality of meaning here which is odd, but is
the only way I understand other people to understand XRIs, and in practice
isn't too much of a problem on the wire.
### When you say, "which is
odd", I think that depends on your starting point definition of "authority".
According to our TC definition, an authority is simply a specific type of
resource: a resource that assigns identifiers for other resources. "xri://@foo*bar"
is the identifier of an authority simply because all resources identified by
the authority segment of an XRI are by definition authorities. To say that an
authority is by definition not a dog, a person, a cat, or a house seems strange
to me because any identifier that represents a non-network resource (dog,
person, cat, house all being non-network resources) clearly cannot actually BE
the non-network resource, but it also clearly REPRESENTS the non-network
resource. For example, my personal XRI, xri://=drummond.reed, clearly isn't actually
ME as a non-network resource, but it does clearly REPRESENT me as a person.
And it represents me as a person completely
separate from the issue of whether any path is involved. In other words, correct
me if I'm wrong, but don't xri://=drummond.reed and xri://=drummond.reed/ represent
the same resource? Since there is no addition identifier present in the latter,
the addition of only the trailing slash as an XRI delimiter does not change the
resource being represented.
Or am I missing something? ###
* An XRI may be resolvable into an XRID
(an XML document) that describes the resource identified by the XRI.
It has always been true that an XRI could
be "resolved" into an XRID. We just never specified how to get
an XRID out of a complete XRI (with a path segment that may or may not be
empty). We only specified how to get XRIDs out of the authority
segment.
### Agreed. The latter functionality is what
some folks on the TC have realized is needed in order to fully resolve an XRI
as an abstract identifier into a concrete identifier. Where this requirement surfaces
most tangibly is in proxy resolution, which is why we are having this
discussion now. ###
* The network endpoint responsible for
assigning an XRI to a resource and returning an XRID describing that resource
is the authority for both the XRI and the corresponding XRID.
Here's where we get into trouble - what is
meant by "the authority". If xri://@foo*bar is an authority, then its
not a dog. Last time I checked, dogs couldn't answer XRI subsegment
resolution requests. But we can just sort of ignore that by saying that the
result of resolution describes the dog and services on the network that act as
a proxy for the dog on the network. In the new conceptualization, we are
saying that resolution of @foo*bar gets back both descriptions of the resource
and network services offered on behalf of (or "relative to"?) that
dog.
### Again, the "new
conceptualization" only applies if the "old conceptualization"
was that a network resource (the target of resolving the XRI
"xri://@foo*bar") was not capable of representing a non-network
resource (a dog) as a proxy on the network. For me, the XRI glossary has always
been clear that many network resources exist to serve as representations of
non-network resources (people, companies, concepts). A non-network resource
(e.g., a dog) can be represented by a network resource having an XRI (e.g.,
xri://@foo*bar), and that network resource can be an authority if it is authoritative
for other XRIs (e.g., xri://@foo*bar*baz or xri://@foo*bar/baz). So I see no
tension between the term "authority" and what kind of non-network
resource it might represent. ###
* One function of XRIDs is to tell XRI
resolvers how to further resolve an XRI. By the above definition, this applies both
to the resolution of authority subsegments within the authority part of an XRI,
and resolution of the local part of the XRI. In other words, XRI resolution is
the complete set of steps that may be necessary to resolve an absolute abstract
XRI into an absolute concrete URI which can then be resolved via DNS, IP, or
other means.
This seems to differ from Dave McAlpin's
assertion that resolution gets you back a descriptor document that can contain
any metadata -- i.e. no need to result in any concrete URI. I'm surprised that
this surprises you - I thought this was your position too.
### Good point. I was too narrow in my
response. Getting back a concrete URI is only one example of the type of metadata
that could be included in a descriptor document. The only thing special about
concrete URIs is when: a) they are needed for further XRI resolution, and b)
they are needed for redirection by HTTP proxy resolvers. ###