[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]