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