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] PLEASE REVIEW: Revised Redirect & Ref Processing Proposal

Hmm everything about the Refs sounds fine.

But I can't say I like the new Redirect proposal very much. I liked the original idea of it being an equivalent mechanism to HTTP redirects (just like HTML has HTTP-EQUIV), but this would mean:
- Allow it ONLY on the XRD level, not Service, so that it doesn't depend on the sep=true parameter.
- Forget synonym verification (I don't understand what that is for anyway).
- Replace the new XRD, not append it (I especially dislike the idea of having multiple XRDs for a single authority in an XRDS).

So that's how I would do it. I don't think it would add complexity, it would be quite simpler. And make it easy to understand the difference between Redirect and Ref. If you see a Redirect on the XRD level, just do an HTTP GET and replace the current XRD. That's it.

But my opinion on this is really not very strong; Your proposal makes sense too, and if others want it to be that way, then that's fine.


On 10/2/07, Drummond Reed <drummond.reed@cordance.net> wrote:
Per the minutes of today's special telecon, I have posted a revised Redirect
and Ref Processing proposal for XRI Resolution 2.0 Working Draft 11 at:


This third draft is now quite mature, and reads pretty closely to how the
new Section 12 of ED06 will read, so close scrutiny by TC members and
implementers is highly desired before it is committed to ED06. I have noted
each significant new point in the proposal using the text...


...in bold so you can concentrate on those points.

Note that this proposal differs in several points from the minutes of
today's meeting because of issues that came up during the writeup:

1) First, it proposes to only allow Redirect and Ref elements as children of
the Service element. On today's call Markus made a case for allowing
Redirect elements at the XRD level, but as I started to write it up, I
realized it will add so much complexity to the spec vs. keeping both
Redirects and Refs at the service level that it did not appear to be worth
it, especially since a consuming application can easily make the decision to
follow a default Redirect. Markus, please review this writeup and post to
the list if you still feel it is worth the additional complexity to allow
Redirects at the XRD level.

2) It proposes that the XRD schema enforce that XRDS authors make a CHOICE
whether any particular SEP contains EITHER zero or more URI elements, zero
or more Redirect elements, or zero or more Ref elements, but not a
combination. This avoids any need to specify precedence.

3) It proposes that Ref elements can only contain XRIs. This is a
simplification from what was discussed on today's call (where we made a case
for Ref elements containing HTTP(S) URIs). This rule helps make the
distinction between Redirect and Ref elements very clean and clear, i.e.:

        - Redirect elements NEVER contain XRIs and NEVER restart CanonicalID
        - Ref elements ALWAYS contain XRIs and ALWAYS restart CanonicalID

4) I specified a clean and simple Next Authority XRI construction rule that
makes it unambiguous what XRDS document is being nested if a Ref is followed
during the authority resolution phase.

5) I added more examples (probably not enough for Victor, but then, there's
never enough examples for Victor).

PLEASE do review and post any feedback, even if it's just +1, before our
next regular telecon on Thursday, as I plan to dive into writing this up in
ED06 this week.



> -----Original Message-----
> From: Drummond Reed [mailto: drummond.reed@cordance.net]
> Sent: Monday, October 01, 2007 9:09 PM
> To: xri@lists.oasis-open.org
> Cc: 'John Bradley'; 'Kermit Snelson'
> Subject: [xri] Minutes: Special XRI TC Telecon 1PM PT Thursday 2007-10-01
> Following are the minutes of the following special unofficial telecon of
> the
> XRI TC at:
> Date:  Monday, 01 October 2007 USA
> Time:  1:00PM - 2:30PM Pacific Time
> Event Description:
> Special telecon to discuss XRI resolution redirect and reference
> processing
> as described in the minutes below.
>     Dial In Number: 571-434-5750
>     Conference ID: 5474
> Gabe Wachob
> Markus Sabadello
> Drummond Reed
> John Bradley
> Kermit Snelson
> Les Chasen
> Wil Tan
> Victor Grey
> This telecon was scheduled after last Thursday's XRI/XDI TC telecon when
> we
> had extensive discussion of Ref processing but were not able to come to
> closure.
> Subsequent discussion produced an updated proposal posted Sunday night,
> 2007-09-30, at:
>       http://wiki.oasis-open.org/xri/XriCd02/RefProcessing
> The three key changes in this new proposal were:
> a) Addition of a Redirect element to take over the function of what was
> previously a "service ref" (which Steve Churchill pointed out operated
> differently than
> an "authority ref").
> b) Keeping the refs= parameter as a boolean (as it was in ED05).
> c) Elimination of the proposed "find all" option -- too complex to be
> introduced at this stage (and can be performed by a separate utility if
> needed).
> Discussion was focused first on the Redirect proposal and secondly on the
> Ref proposal.
> Following are the highlights of the discussion about the Redirect
> proposal.
> * First, it was clarified that in essence, the Redirect element is simply
> a
> new name for what in XRI Resolution 2.0 Working Draft 11 ED05 was called a
> service ref (section 12.2).
> * The primary use case for a Redirect element is remote administration of
> an
> XRDS, i.e., it allows an XRI to be registered in a registry while the
> actual
> service endpoints (SEPs) associated with that XRI can be managed in
> another
> domain.
> * Kermit asked: will it take the same append and priority attributes as
> the
> URI element. The consensus was that yes, it should.
> * Kermit then summarized it this way: a Redirect element is a child of the
> Service element. It accepts the same attributes as the URI element. It
> be an HTTP(S) URI, just like the URI element in an authority resolution
> SEP.
> When processed, the same service endpoint selection process is performed
> on
> the target XRDS (the one returned as a result of the Redirect). Also,
> synonym equivalence is verified. If saml=true, both the source and target
> redirects MUST be signed by the parent authority.
> * Markus pointed out that a Redirect could be at the XRD level, and that
> should be supported because an XRDS may contain metadata besides service
> endpoints.
> * Victor asked for some additional examples.
> * After much discussion, there was a consensus that all the XRDs being
> traversed by the resolver should be shown in the final XRDS document,
> i.e.,
> that a redirect caused by a Redirect element should not be transparent to
> the final XRDS like an actual HTTP(S) redirect.
> # DRUMMOND to make the following changes to the Redirect proposal at
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing.
> 1) Specify that the Redirect element takes the append and priority
> attributes.
> 2) Specify that the Redirect element may appear at both the XRD and
> Service
> levels.
> 3) Specify that a successful Redirect MUST result in an additional XRD
> appended to the current XRDS. This XRDS MUST have a redirect attribute
> showing the value of the fully-constructed Redirect URI.
> 4) Clarify that Redirect processing NEVER produces a new CanonicalID
> verification chain, whereas Ref processing (below) ALWAYS produces a new
> CanonicalID verification chain.
> 5) Add examples showing CanonicalID verification.
> * We continued the discussion from last week about whether a Ref should
> necessarily start a new CanonicalID verification chain. There was
> consensus
> that it should, but Les was still uneasy that the final XRD(s) in this
> chain
> appeared under the new XRDS instead of the parent XRDS that spawned the
> Ref.
> * Wil said that applications should be able to obtain the CanonicalID for
> a
> QXRI without the need for any additional service endpoint selection
> parameters taken into account, which we confirmed could be done by
> resolving
> without any service endpoint selection parameters. We agreed the
> CanonicalID
> produced under this query may be different than that produced if the QXRI
> includes service endpoint selection parameters. Consuming applications can
> then take their choice of the identifier(s) they wish to store.
> * We clarified that Ref may contain either an XRI or an HTTP(S) URI. If it
> contains the latter, it is resolved according to section 6 (the Yadis
> section). It is a very important point that even if the Ref contains an
> HTTP(S) URI, it is NOT processed like a Redirect, but as the start of a
> new
> CanonicalID verification chain. The only CanonicalID that can be verified
> in
> this chain is either the original HTTP(S) URI itself or the original
> URI plus a fragment.
> * Victor suggests that we specify that if any CanonicalID is not verified,
> the rest of the chain does not verify. There was concensus that this
> should
> be the case for both Redirect and Ref.
> # DRUMMOND to make the following changes to the Redirect proposal at
> http://wiki.oasis-open.org/xri/XriCd02/RefProcessing :
> 1) Specify processing for both an XRI and an HTTP(S) URI.
> 2) Specify that if at any point in Redirect or Ref processing, a
> CanonicalID
> is not verified, the rest of the CanonicalID chain does not verify.
> 3) Add additional examples of CanonicalID verification.
> # DRUMMOND to answer the message Steve posed to the list about XRDS
> nesting.

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