[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRI Res ED 08 decision - need feedback
I like this very much! A bonus is that we only need a single MIME type for both application/xrd+xml and application/xrd-saml+xml because the latter is exactly the same as the former (there is no SAML data in there!) However, the question is, do we keep application/xrds-saml+xml or do we get rid of it in favor of the "trusted" MIME parameter? The argument for keeping it is that it contains SAML data unlike plain XRDS. On the flip side, one could also argue that XRDS contains optional SAML data, so xrds-saml+xml is really just a specialization of the XRDS media type. =wil (http://xri.net/=wil) > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Tuesday, March 07, 2006 12: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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]