RE: [xri] Piling on

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

It should also be noted that the _xrd_r can alternatively be specified on
the http accept header. (The query argument has precedence.)

~ Steve


> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, March 07, 2006 10:37 AM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] Piling on
> 
> Gabe,
> 
> No, you are correct, the use of the media type parameters doesn't do away
> with the need for query parameters in HXRIs. That's not what we were
> jazzed
> about.
> 
> What we liked about was the ability to use media type parameters to
> eliminate the growing number of query parameters that were being needed,
> and
> to make those parameters more intuitive for developers.
> 
> Here's an example. The first HXRI is the old way of using separate query
> parameters for _xrd_a (Authority Media Type), _xrd_n (No-Follow-Refs
> Flag),
> and _xrd_s (Service Endpoint Selection Flag) in addition to _xrd_r (Return
> Media Type).
> 
> http://xri.net/@a*b*c/foo?_xrd_t=xri://+contact&_xrd_m=text/html
> &_xrd_a=application/xrds-saml+xml&xrd_r=application/xrd+xml&_xrd_n=true
> &_xrd_s=true
> 
> Now, here's the same thing with _xrd_a, _xrd_n, and _xrd_s all now folded
> into media type parameters on the value of _xrd_r:
> 
> http://xri.net/@a*b*c/foo?_xrd_t=xri://+contact&_xrd_m=text/html
> &_xrd_r=application/xrd+xml;trust=saml;sep=true;refs=false
> 
> The latter seems much cleaner.
> 
> =Drummond
> 
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Tuesday, March 07, 2006 9:37 AM
> To: Drummond Reed; xri@lists.oasis-open.org
> Subject: RE: [xri] Piling on
> 
> I thought the point of these query parameters was that they should be
> includable in a HTTP URI that can be (for example) stuck in a web page.
> 
> Preferred media type (afaik) cannot be attached to a HTTP URI (via a <A>
> HTML tag, for example).
> 
> The use of the media type options doesn't do away with the need for
> query parameters, does it? At least for HXRIs? Or am I missing
> something?
> 
> 	-Gabe
> 
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, March 06, 2006 10:47 PM
> > To: xri@lists.oasis-open.org
> > Subject: [xri] Piling on
> >
> > As I finish the completely revised Inputs and Outputs section
> > of Working
> > Draft 10 Editor's Draft 08, using this new media type
> > parameter architecture
> > (Gabe has no idea what he's set off here), I of course
> > realized that the
> > NoFollowRefs parameter also fell perfectly into the bucket of
> > resolution
> > controls that should be specified by media type parameters
> > and thus not
> > require a separate proxy resolution query parameter.
> >
> > So I've revised
> > http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionExampleApi
> > again (for the sixth time today -- great use of a wiki) to
> > update it for
> > this addition.
> >
> > That means that authority resolution is down to two parameters:
> >
> > * QXRI
> > * Resolution Media Type (_xrd_r)
> >
> > And service endpoint selection adds just two more parameters:
> >
> > * Service Type (_xrd_t)
> > * Service Media Type (_xrd_m)
> >
> > This is going in exactly the right direction: simpler, more
> > flexible, and
> > easier to understand.
> >
> > Look to see it all in print in Editor's Draft 08 tomorrow
> > (which we will
> > review on Thursday's TC call at 4PM Pacific.)
> >
> > =Drummond
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, March 06, 2006 9:30 PM
> > To: xri@lists.oasis-open.org
> > Subject: [xri] Make https a value of trust media type parameter?
> >
> > All,
> >
> > After Gabe made this breakthrough suggestion about using media type
> > parameters (where was he a week ago when this could have
> > saved us a good man
> > day of work!! ;-), it then prompted Steve to mention that
> > Peter Davis has
> > has a very compelling use case for requiring XRI authority
> > resolution and
> > SEP selection that uses all https service endpoints.
> >
> > So Steve suggests that we add the value of "https" to the
> > "trust" media type
> > parameter on application/xrds+xml and application/xrd+xml.
> >
> > This of course would mean adding one subsection to the
> > Authority Resolution
> > section of the spec that simply specifies that if the value
> > of the "trust"
> > attribute is "https", then all auth res requests must use https (and a
> > corresponding error message).
> >
> > This is a very cheap and lightweight way to get a "poor man's
> > trusted res"
> > in Working Draft 10.
> >
> > What does everyone think?
> >
> > =Drummond
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, March 06, 2006 6:31 PM
> > To: 'Wachob, Gabe'; 'Tan, William'; 'Steven Churchill';
> > xri@lists.oasis-open.org
> > Subject: RE: [xri] XRI Res ED 08 decision - need feedback
> >
> > Gabe, you are a lifesaver. I totally forgot about this
> > option. Media type
> > parameters are exactly what we need.
> >
> > I just completely updated the proxy resolver mapping proposal at:
> >
> > 	http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionExampleApi
> >
> > See the final section. In short, there are now just three
> > defined media
> > types:
> >
> > application/xrds+xml
> > application/xrd+xml
> > text/uri-list
> >
> > The first two accept the "sep" parameter whose values are
> > boolean "true" and
> > "false". All three accept the "trust" parameter whose values
> > are "none" and
> > "saml".
> >
> > Examples:
> >
> > application/xrds+xml;trust=saml
> > application/xrds+xml;sep=true;trust=saml
> > application/xrd+xml;sep=true
> > text/uri-list;trust=saml
> >
> > Gabe, are you comfortable with us adding the "trust" parameter to
> > text/uri-list, given that it's not our spec? I'm fine with it
> > because: a) it
> > doesn't conflict w/any other parameters (there are none that
> > I saw), and b)
> > we are the only ones consuming this parameter.
> >
> > =Drummond
> >
> >
> > -----Original Message-----
> > From: Wachob, Gabe [mailto:gwachob@visa.com]
> > Sent: Monday, March 06, 2006 5:10 PM
> > To: Drummond Reed; Tan, William; Steven Churchill;
> > xri@lists.oasis-open.org
> > Subject: RE: [xri] XRI Res ED 08 decision - need feedback
> >
> > I'd prefer to keep the SAML extension for the reasons provided.
> >
> > I think the trust mechanism is likely to be the first place where
> > extensions (private or public) are likely to occur. I don't want to
> > suggest there is only one trust mechanism possible.
> >
> > In addition, I don't know that we really want to mess with
> > text/uri-list
> > by creating a derivate text/uri-list-trusted (or -saml). It feels like
> > we'd be stepping on someone else's specification.
> >
> > Have we considered using MIME parameters instead of a
> > plethora of media
> > types?
> >
> > Something like:
> > application/xrds+xml; trusted=saml
> > application/xrds+xml; trusted=none
> > application/xrd+xml; filtered=sep
> >
> > Just seems to be more in line with the intent of RFC 2045. Here's the
> > language:
> >
> >   "Parameters are modifiers of the media subtype, and as such do not
> >    fundamentally affect the nature of the content.  The set of
> >    meaningful parameters depends on the media type and subtype.  Most
> >    parameters are associated with a single specific subtype.
> > However, a
> >    given top-level media type may define parameters which are
> > applicable
> >    to any subtype of that type.  Parameters may be required by their
> >    defining content type or subtype or they may be optional. MIME
> >    implementations must ignore any parameters whose names they do not
> >    recognize."
> >
> >
> >    -Gabe
> >
> > > -----Original Message-----
> > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > Sent: Monday, March 06, 2006 4:40 PM
> > > To: 'Tan, William'; 'Steven Churchill'; xri@lists.oasis-open.org
> > > Subject: RE: [xri] XRI Res ED 08 decision - need feedback
> > >
> > > Wil, I was thinking about that too. However as I understand
> > > it, one of the
> > > reasons Gabe and Dave originally chose to put "-saml" in the
> > > media type was
> > > because over time there could be other trusted resolution
> > > protocols using
> > > other trust assertion formats.
> > >
> > > Thus "-saml" does more than specify you want SAML-based
> > assertions, it
> > > specifies the type of resolution protocol you want used.
> > >
> > > So we have a choice. We can either adopt "-trusted"
> > > throughout and say that
> > > this means the resolver's choice of trusted resolution
> > protocol (with
> > > originally there are only one), or we can use "-saml"
> > > throughout to mean the
> > > resolver should use the SAML-based XRI trusted resolution protocol.
> > >
> > > What do folks think?
> > >
> > > =Drummond
> > >
> > > -----Original Message-----
> > > From: Tan, William [mailto:William.Tan@neustar.biz]
> > > Sent: Monday, March 06, 2006 3:52 PM
> > > To: Steven Churchill; xri@lists.oasis-open.org
> > > Subject: RE: [xri] XRI Res ED 08 decision - need feedback
> > >
> > > That's fine with me.
> > >
> > > I'd prefer to use "-trusted" rather than "-saml" in the following
> > > (non-XRDS) _xrd_r values since they do not actually contain SAML
> > > signatures:
> > >
> > > application/xrd-trusted+xml
> > > application/xrds-trusted-sep+xml
> > > application/xrd-trusted-sep+xml
> > > text/uri-list-trusted
> > >
> > >
> > > =wil (http://xri.net/=wil)
> > >
> > >
> > > > -----Original Message-----
> > > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > > Sent: Tuesday, March 07, 2006 9:21 AM
> > > > To: xri@lists.oasis-open.org
> > > > Subject: RE: [xri] XRI Res ED 08 decision - need feedback
> > > >
> > > >
> > > > Here is an observation for readers of this proposal. It is
> > > an attempt
> > > to
> > > > add
> > > > lucidity (but may very well accomplish the opposite.) :-)
> > > >
> > > > Here goes: In Proposal #3 at the end, for the last row in
> > the table
> > > > (text/uri-list-saml), the (logical) mapping to function #5 would
> > > involve
> > > > authMediaType taking on the value of application/xrds-saml+xml.
> > > >
> > > > ~ Steve
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > > > Sent: Monday, March 06, 2006 1:31 PM
> > > > > To: xri@lists.oasis-open.org
> > > > > Subject: [xri] XRI Res ED 08 decision - need feedback
> > > > >
> > > > > XRI Resolution Editors (and any other TC member interested):
> > > > >
> > > > > Thanks to Steve, we now have an example local resolver API which
> > > will
> > > > > become
> > > > > non-normative Appendix C in Editor's Draft 08 of
> > Working Draft 10
> > > (the
> > > > > last
> > > > > of these "Editor's Drafts"). This API is document on the
> > > TC wiki at:
> > > > >
> > > > >
> > http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionExampleApi
> > > > >
> > > > > Once we finished this example local API, it brought up several
> > > options
> > > > for
> > > > > how it could be mapped more efficiently to the proxy
> > resolver API
> > > that
> > > > we
> > > > > do
> > > > > normatively specify. Steve and I batted around the
> > > options over the
> > > > > weekend,
> > > > > and we ended out with three proposals that are listed at
> > > the bottom
> > > of
> > > > the
> > > > > page above.
> > > > >
> > > > > The one Steve and I are leaning towards is #3, which
> > collapses all
> > > the
> > > > > choices about resolution type and return type and
> > service endpoint
> > > > > selection
> > > > > into one list of media types. Besides reducing three
> > > potential proxy
> > > > > resolver parameters (_xrd_a, _xrd_r, and a possible
> > > _xrd_s) to just
> > > one
> > > > > (_xrd_r), it also has the advantage of allowing XRI
> > communities to
> > > > > advertise
> > > > > the precise capabilities of their XRI proxy resolvers.
> > > > >
> > > > > Under this proposal the list of media types that could be
> > > offered by
> > > an
> > > > > XRI
> > > > > proxy resolver would be:
> > > > >
> > > > > application/xrds+xml
> > > > > application/xrds-saml+xml
> > > > > application/xrd+xml
> > > > > application/xrd-saml+xml
> > > > > application/xrds-sep+xml
> > > > > application/xrds-saml-sep+xml
> > > > > application/xrd-sep+xml
> > > > > application/xrd-saml-sep+xml
> > > > > text/uri-list
> > > > > text/uri-list-saml
> > > > >
> > > > > Note that only the first two of these are the media types
> > > for an XRI
> > > > > authority server. The other 8 are all for proxy resolvers only.
> > > > >
> > > > > Since I'm writing this into the spec this afternoon, I'd
> > > love to get
> > > > > feedback. Do folks agree that expanding the list of
> > media types to
> > > cover
> > > > > all
> > > > > these options is the cleanest way to specify the proxy resolver
> > > > interface?
> > > > > If so, these would become the values of the _xrd_r
> > parameter. The
> > > only
> > > > > other
> > > > > parameters (besides the QXRI) would be:
> > > > >
> > > > > _xrd_t	Service Type
> > > > > _xrd_m	Media Type
> > > > > _xrd_n	No-Follow-Refs Flag
> > > > >
> > > > > Thanks for any feedback -- I'm aiming to publish
> > Editor's Draft 08
> > > > > tomorrow,
> > > > > hold final review on Thursday's TC call, and publish the final
> > > Working
> > > > > Draft
> > > > > 10 on Friday.
> > > > >
> > > > > =Drummond
> > > > >
> > > > >
> > > > >
> > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe from this mail list, you must leave the
> > > OASIS TC that
> > > > > generates this mail.  You may a link to this group and
> > > all your TCs
> > > in
> > > > > OASIS
> > > > > at:
> > > > >
> > >
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > > >
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe from this mail list, you must leave the
> > OASIS TC that
> > > > generates this mail.  You may a link to this group and all
> > > your TCs in
> > > > OASIS
> > > > at:
> > > >
> > >
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > generates this mail.  You may a link to this group and all
> > > your TCs in OASIS
> > > at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > > oups.php
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > generates this mail.  You may a link to this group and all
> > > your TCs in OASIS
> > > at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > > oups.php
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all
> > your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all
> > your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all
> > your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php