When considering transformations from XRI to URI, the
URI has to handle anything the XRI supports; however, the XRI does not have
to handle everything that URI supports.
I think that maintaining support for unnecessary
fragments in XRI just so they can be transformed into URIs with unnecessary
fragments is not sufficient justification.
Marty.Schleiff@boeing.com;
CISSP Associate
Technical Fellow - Cyber Identity Specialist Computing Security
Infrastructure (206)
679-5933
This has been a good
discussion. I thought about it on my run this morning and came up with the
strongest reason that, as much as we may not like fragments, we should not
remove them from the ABNF in the XRI 3.0 spec.
The reason is that, as
abstract identifiers, XRIs are frequently mapped to, or “transformed to”,
concrete URIs. That’s essentially what the XRI resolution process does: take an
abstract XRI and go through a set of transformations to turn it into one or more
concrete URIs that identify the target resource in the context of a specific
service.
For example, following
are the set of transformation that turn the XRI =a*b*c/path#frag into a URI.
Each step of the process (corresponding to an XRD) gradually replaces the
authority subsegments with HTTP(S) URIs and appends the rest of the XRI. For
example:
Start:
=a*b*c/path#frag
Transformation #1:
https://equals.xri.net/*a*b*c/path#frag
Transformation #2:
https://first.authority.example.com/*b*c/path#frag
Transformation #3:
https://second.authority.example.com/*c/path#frag
Transformation #4:
https://third.authority.example.com/path#frag
If we remove the
ability for XRIs to carry fragments, we remove the ability for the final URI
coming out of the final transformation to have a
fragment.
Since there are many
use cases for concrete URIs to have fragments (whether we like it or not), I
think we have no choice but to retain support for fragments to support those
same URIs having abstract XRIs.
I do agree with Marty
that from the standpoint of XRI identification, the XRI 3.0 spec should capture
his main point (and remain consistent with the URI spec) by stating that, “An
XRI fragment MUST NOT change the resource being identified by the XRI”. In other
words, fragments are ignored when it comes to comparison of the “base
resource”.
=Drummond
From: Chasen,
Les [mailto:les.chasen@neustar.biz] Sent: Saturday, September 15, 2007 8:52
AM To: Barnhill, William;
Schleiff, Marty; xri@lists.oasis-open.org Subject: RE: [xri] RE: Yucky
Fragments
The only use fragments
bring (I believe) is to the client application via sep selection. The
service endpoint can be defined to pass any number of parts (none, local,
authority, path, query, qxri) of the qxri to the client via the defined service
uri append option. I believe that qxri would be the only option to include
the fragment along with everything else. The client application could then
use the fragment for local processing.
I have no personal
affinity for fragments. I think it would be fine to discuss dropping
support for them when the syntax spec is next looked at.
From: Barnhill,
William [mailto:barnhill_william@bah.com] Sent: Saturday, September 15, 2007 9:20
AM To: Schleiff, Marty;
xri@lists.oasis-open.org Subject: [xri] RE: Yucky
Fragments
Hi Marty,
Agreed, I'd have no problem dropping
fragments as I think // gets us there as well and having one method is probably
best. The only downside is that fragment support already is in the browser
(for a limited set of mime types). This will be resolved when someone adds
better XRI support, which Wil's plugin has already started to do.
And
yeah, I'm facing the same issue with OpenID and corporate adoption. Until you
can convince corporate IT that it is secure they won't adopt it. Doesn't help
that there's been a lot of FUD about OpenID security, but IMHO they also need to
address security more. I'm hoping trusted XRI resolution + OpenID +
browser extension will work. Verisign seems to be doing something
similar.
Bill
-----Original Message----- From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com] Sent:
Fri 9/14/2007 5:49 PM To: Barnhill, William;
xri@lists.oasis-open.org Subject: RE: Yucky Fragments
Hi Bill
& All,
Sounds like you understand my confusion about fragments.
Rather than come up with an 'about' service to deal with things like
fragments, I'd rather just drop support for fragments.
OpenID and
OpenID Identity Providers probably have to come a long way to be palatable to
a corporation like my employer. However, there's so much energy and
innovation in the OpenID area, I'd be foolish to ignore
it.
Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow -
Cyber Identity Specialist Computing Security Infrastructure (206)
679-5933
________________________________
From: Barnhill,
William [mailto:barnhill_william@bah.com] Sent:
Friday, September 14, 2007 1:24 PM To: Schleiff, Marty;
xri@lists.oasis-open.org Subject: RE: [xri] Yucky
Fragments
Ahh, I think I see the problem, and it's one I
think everyone (XRI, XDI, and RDF communities) are struggling with. When the
identifier identifies a person (or other non-web entity)...what does
resolution mean? Usually this works out to exactly what you said Marty,
=Bill.Barnhill would probably be expected to resolve to a online resource
that describes the offline resource (in this case me :).
I think this
leads to questions that AFAIK we haven't nailed down yet, with yours at the
top of the list (I changed the name as I've taken to only using example
identifiers I have control over, just to be safe): 1) Does =Bill.Barnhill
refer to me (who is not a web resource), or to the XRDS containing my service
points? 2) If not, does it refer to a particular service endpoint
type...an 'about' service? 3) What do local identifier parts (# and/or //)
mean in this context?
My personal thought is that users should have the
option of expressing metadata in any format, not just XRDS, so I'm for an
'about' service that explicitly returns metadata (type is determined through
mime-type selection as in normal resolution). This would lead to what's IMHO
an elegant solution, resolution with SEP of =Bill.Barnhill returning a
303 "see other" that goes to the URI where the metadata is located
(could still be XRDS) if and only if a service of the
type <Type>xri://$res*about*($v*2.0)</Type> is matched in the XRD
describing the resolution of =Bill.Barnhill. The same URI would be returned
for =Bill.Barnhill*($res*about), which would preserve the 'about'
capability and allow XRD maintainers the option of overriding the default
'about' behavior with a redirect to a contact page, home apge,
etc.
I'd like to hear from people on whether they think this 'about'
service type has enough merit to be included in 2.1 specs.
Btw, the
303 idea is not an original idea of mine, see http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/#303uri.
On
the spec being difficult to understand, I too have the same problem. I'd love
to say it should be simplified, but (a) I neither had nor have the time to
put money where my mouth is an d offer to edit (too many other fires), (b)
the spec may be as simple as it can be and still nail things down. IMHO
the spec (and our others) will undergo a trial by fire when fully released as
implementers will either use it, or not. A big indicator for me will be
whether the OpenID community can be persuaded to switch over time to using
2.0 XRIs as their main type of OpenID, and trusted resolution as a means to
address some of the security criticisms that have been made. Whether
those criticisms are fair or unfair, I think trusted XRI resolution could
dramatically raise OpenID adoption in the corporate world (if the two are or
can be made compatible).
-----Original Message----- From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com] Sent:
Fri 9/14/2007 3:17 PM To: Barnhill, William;
xri@lists.oasis-open.org Subject: RE: [xri] Yucky Fragments
Thanks for
responding Bill. This is how I learn.
I argue that "=marty" is my
identifier, not my address. The XRDS returned upon resolution of "=marty" may
include addresses of my various service points.
The resolution spec is
very difficult for me to understand (as are most other specs). In "=marty",
does "..the target resource identified by the combination of Authority, Path,
and Query components ..." refer to me (not a web resource), or to the XRDS
containing my service points?
Marty.Schleiff@boeing.com;
CISSP Associate Technical Fellow - Cyber Identity Specialist Computing
Security Infrastructure (206)
679-5933
________________________________
From: Barnhill,
William [mailto:barnhill_william@bah.com] Sent:
Friday, September 14, 2007 12:03 PM To: Schleiff, Marty;
xri@lists.oasis-open.org Subject: RE: [xri] Yucky
Fragments
Marty, you said "The XRI is the identifier of the
resource, NOT the address of the resource." I thought that was one of the
big selling points of XRI, the identifier is an address.
On fragments
in XRIs...I think they serve a purpose, but not one in resolution. The
meaning of fragments that I originally learned was that they were not for the
server but were an index into the representation(s) returned by the
server. This means they're not intended for use by the server, but by
the consuming application (the browser). The quote you gave from
RFC3986 seems to indicate the same thing.
For XDI we have the //
syntax, though I think we could define that better and do not know if that is
in the current XRI spec. For me // has always indicated a hierarchical
index within the representation returned by an XRI resolution. You could do
away with # in favor of //, but by keeping it you have both a hierarchical
index (//) and a flat index. IMHO though both are dealt with by the consuming
application, and should be ignored for the purpose of
resolution.
Looking at WD 11 of the XRI resolution spec, it seems to
agree: 878 The fourth possible component of a QXRI-a fragment-is by
definition resolved locally relative 879 to the target resource identified
by the combination of the Authority, Path, and Query 880 components, and
as such does not play a role in XRI
resolution.
Bill
-----Original Message----- From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com] Sent:
Fri 9/14/2007 2:11 PM To: xri@lists.oasis-open.org Subject: [xri] Yucky
Fragments
Hi All,
Now that Drummond is working for Parity, he
doen't have as much time to deal with my opinions. Too bad for the rest of
you, that means I now have to pester you more.
I've never liked
fragments in XRIs; I think XRI should not allow fragments.
Do the
following XRIs represent the same resource?
@boeing*resource*abc#top
@boeing*resource*abc#middle
@boeing*resource*abc#bottom
Do they return the same XRDS? Does each
fragment identify a piece of the XRDS, or does it get tacked onto the back of
a service point URI, or get tacked onto the back of every service point URI,
or what?
RFC3986 (spec for URI) says this about fragments:
"The
semantics of a fragment identifier are defined by the set of representations
that might result from a retrieval action on the primary resource. The
fragment's format and resolution is therefore dependent on the media type
[RFC2046 </rfcs/rfc2046.html> ] of a potentially retrieved
representation, even though such a retrieval is only performed if the URI is
dereferenced." Does that mean the same fragment value might mean different
things to a resource's various service end points supporting different media
types?
Marty.Schleiff@boeing.com; CISSP Associate Technical Fellow -
Cyber Identity Specialist Computing Security Infrastructure (206)
679-5933
I did not miss your point. The XRI is the identifier of the
resource, NOT the address of the resource. If anything, it's the address of
the resource descriptor. The resource descriptor then may point to
the address of the resource, including a fragment in the service point
URI.
If two resources are fragments of the same web page, then they
should have separate XRIs (with no fragments) and separate XRDs with
different service points. The service points URIs would be the same except
for different fragments.
Does the Resolution spec say to take the
fragment from the XRI and append it to the service point URI? I doubt it and
I hope not (but I don't know cuz I'm not working on
Resolution).
Marty.Schleiff@boeing.com; CISSP Associate Technical
Fellow - Cyber Identity Specialist Computing Security Infrastructure (206)
679-5933
-----Original Message----- From: Drummond Reed [mailto:Drummond.Reed@parityinc.net] Sent:
Friday, September 14, 2007 9:21 AM To: Schleiff, Marty Subject: RE:
fragments
I think you missed my point. The fragment isn't necessarily
important to the XRI that identifies the target resource (via the target
resource descriptor), it's important to the RESOURCE. The XRI, being the
abstract address of the resource, needs to be able to "carry" the fragment
for exactly the same reason that HTTP(S) URIs need to be able to carry
the fragment: because some applications need to be able to address not
just the resource but "inside" the resource. The fragment plays
absolutely zero role in resolution and network processing of HTTP(S) URIs,
but it plays a vital role in URI *addressing* of resources for this
very reason.
The same is true of XRIs. Net net: XRI can no more afford
to drop fragments (or queries) than URIs
can.
******** <ASIDE> Now that I'm working with Parity, it's
like my whole life has been thrown into fast-forward. It's really intense.
It's really good, because XRI and XDI are absolutely vital components of
Parity's (and Higgins) work now, so we're getting loads and loads of daily
hands-on feedback, and I think Higgins will have a huge impact on XRI and
XDI adoption.
The downside, if you look at it that way, is that I'm
not going to have as much time to discuss XRI and XDI topics in the abstract
-- which is what we have a lot of fun doing. It's not that I want to
discourage exploration -- you have brought several breakthrough ideas to both
XRI and XDI (your's and Laurie's critique of the XDI ATI model sparked
the entire breakthrough to XDI RDF). But I'm going to be quicker to give
you feedback if I think particular topic/exploration angle is or a
dead-end. (I may be wrong, of course, but I'll be quicker to put a stake in
the ground, just for efficiency's sake).
This is one example. As much
as it might appeal for aesthetic reasons -- I think fragments are ugly too --
from a legacy standpoint we're stuck with them. Secondly, the principal the
XRI TC has followed is to maintain the highest possible compatability with
URI architecture.
Add those two together and my belief is the topic is a
dead-end. If you feel strongly about this, by all means take the case to the
TC list and see if you can find any support for it.
I hope you
understand -- I don't want to stifle innovation, but I also need to get
enough sleep so I don't get a heart attack ;-) </ASIDE>
Talk to you
at 2PM.
=Drummond
> -----Original Message----- >
From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] >
Sent: Friday, September 14, 2007 8:36 AM > To: Drummond Reed >
Subject: RE: fragments > > You said: "That's true at the XRI
resolution level, yes. But that's > also true at the URI resolution level
as well, i.e., with browsers and URLs. > The place the fragment comes
in is AFTER resolution, inside the > returned resource. That's where XRIs
could use fragments just like > URIs. For example, if an XRI returned a
web page, the fragment could > be used to address a fragment inside the
page." > > I think this is hokey. XRI isn't supposed to return a web
page (i.e., > a resource); rather, it returns the resource
descriptor. If the > described resource is a web page, then the XRD
might include a service
> point that includes a fragment, but the XRI
should not include a > fragment. I don't think a fragment inside an XRDS
page makes sense. > Unless maybe (and I don't like this) it's indicating a
particular XRD in an XRDS. > > > Marty.Schleiff@boeing.com;
CISSP > Associate Technical Fellow - Cyber Identity Specialist
Computing > Security Infrastructure > (206) 679-5933 > >
-----Original Message----- > From: Drummond Reed [mailto:Drummond.Reed@parityinc.net] >
Sent: Thursday, September 13, 2007 11:12 PM > To: Schleiff, Marty >
Subject: RE: fragments > > Inline. > > >
-----Original Message----- > > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] >
> Sent: Thursday, September 13, 2007 8:33 AM > > To: Drummond
Reed > > Subject: RE: fragments > > > > OK - query
strings should stay. But fragments only add confusion. In
> > the
returned XRDS, I think the <query> (or something like that) > >
shows the XRI being resolved. > > Yes, it's the <Query>
element. > > > Would that include the fragment? > >
No. > > > So the only > > difference in the returned
XRDs's would be in the <query>? > > Yes. > > >
If the > > fragment isn't included in the query, then I'd argue that
the > > fragment > > > is ignored, and the 3 example
XRIs below are equivalent. > > That's true at the XRI resolution
level, yes. But that's also true at > the URI resolution level as well,
i.e., with browsers and URLs. The > place the fragment comes in is AFTER
resolution, inside the returned > resource. That's where XRIs could use
fragments just like URIs. For > example, if an XRI returned a web page,
the fragment could be used to > address a fragment inside the
page. > > > Does OpenID need a fragment on XRIs, or just on
URIs? > > If you're talking about the OpenID recycling issue, only
HTTP(S) URIs. > We have a different way of solving the persistent
identifier mapping > issue. > > =Drummond > >
> > > Marty.Schleiff@boeing.com; CISSP > > Associate
Technical Fellow - Cyber Identity Specialist Computing > > Security
Infrastructure > > (206)
679-5933
|