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] RE: Yucky Fragments


Title: RE: [xri] RE: Yucky Fragments

Ah, that's a problem then. IMHO a strong +1 for this issue of complete transformation abilities tobe solved in XRI 3. Fortunately I think a solution already exists, kind of. Ruby has something called Active Routing (may have name wrong, not sure) that is kind of a regex for URIs.  We could use something similar for XRIs that allowed things like
=Bill.Barnhill/todo/$(time) ..this uses the var syntax I'm using in other code, prob needs to be changed to something compatible with new specs.. to http://example.org/~bill/todo#$(time). This would call for an additional attribute in the XRD though: transform. This would be a more complex op than append, and append could be represented as the following transform
$(authority)/$(rest) => http://example.org/$(rest).  All this would need to be tied into matchers, and gone over as the above is a first shot from the hip.

You are going to have people wanting 'clean'/'cool' XRIs the same way they do with URIs, and I think something like the above will be needed.


-----Original Message-----
From: Chasen, Les [mailto:les.chasen@neustar.biz]
Sent: Mon 9/17/2007 11:12 AM
To: Barnhill, William; Drummond Reed; Schleiff, Marty; xri@lists.oasis-open.org
Subject: RE: [xri] RE: Yucky Fragments

Unfortunately no.  If a SEP is configured to pass data into the SEP's
URI using the append attribute the resolver takes the QXRI and strips of
the component indicated by the append attribute.   It would have no way
to convert a path subsegement to a fragment. 



contact: =les <http://xri.net/=les>

voice: =les/(+phone) <http://xri.net/=les/(+phone)>

chat: =les/skype/chat <http://xri.net/=les/skype/chat>

pibb me  =les/+pibb <http://xri.net/=les/+pibb>









________________________________

From: Barnhill, William [mailto:barnhill_william@bah.com]
Sent: Monday, September 17, 2007 7:50 AM
To: Drummond Reed; Schleiff, Marty; Chasen, Les;
xri@lists.oasis-open.org
Subject: RE: [xri] RE: Yucky Fragments





Could =Bill.Barnhill/todo/0800 be made to resolve to
http://example.org/~bill/todo#0800 as easily as =Bill.Barnhill/todo#0800
can?  If both are possible the first looks cleaner IMHO.

Bill

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Mon 9/17/2007 3:28 AM
To: 'Schleiff, Marty'; 'Chasen, Les'; Barnhill, William;
xri@lists.oasis-open.org
Subject: RE: [xri] RE: Yucky Fragments

I'm not saying the fragments are unnecessary in URIs. The are necessary
in
the URIs that use them. Therefore they are necessary in the XRIs that
might
be assigned as abstract identifiers for the URIs that use them.



=Drummond



  _____

From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
Sent: Saturday, September 15, 2007 11:24 PM
To: Drummond Reed; Chasen, Les; Barnhill, William;
xri@lists.oasis-open.org
Subject: RE: [xri] RE: Yucky Fragments



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





  _____

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Saturday, September 15, 2007 1:30 PM
To: 'Chasen, Les'; 'Barnhill, William'; Schleiff, Marty;
xri@lists.oasis-open.org
Subject: RE: [xri] RE: Yucky Fragments

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.



contact:  <http://xri.net/=les> =les

voice <http://xri.net/=les/(+phone)> : =les/(+phone)

chat:  <http://xri.net/=les/skype/chat> =les/skype/chat

pibb me  =les/+pibb <http://xri.net/=les/+pibb>









  _____

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






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