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