OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] XRI Res ED 08 decision - need feedback


Wil, I wasn't even going to define the "sep" parameter for text/uri-list.
Only the "trust" parameter. So we can avoid that problem completely.

=Drummond 

-----Original Message-----
From: Tan, William [mailto:William.Tan@neustar.biz] 
Sent: Monday, March 06, 2006 6:54 PM
To: xri@lists.oasis-open.org
Subject: RE: [xri] XRI Res ED 08 decision - need feedback

Should we put in a firmer clause like "The text/uri-list media type
SHOULD NOT be accompanied by the 'sep' parameter unless its value is
'true'"?

=wil (http://xri.net/=wil)
 
 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, March 07, 2006 1:39 PM
> To: Tan, William; xri@lists.oasis-open.org
> Subject: RE: [xri] XRI Res ED 08 decision - need feedback
> 
> Yes, Wil, I like this very much. Our messages crossed in the mail. I
think
> Gabe nailed it -- we should deprecate the application/xrds-saml+xml
media
> type (which was new since CD 01 anyway -- back then it was
> application/xrid-saml+xml) and just keep application/xrds+xml.
> 
> See the message I just posted and the updated web page at...
> 
> 	http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionExampleApi
> 
> ...and send me any feedback ASAP.
> 
> =Drummond
> 
> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz]
> Sent: Monday, March 06, 2006 5:44 PM
> To: xri@lists.oasis-open.org
> 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
> > >
> > >
> 
> ---------------------------------------------------------------------
> 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]