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] Decision on Ref "backtracking" issue


I think the reason you'll see hierarchical XML over the wire is for
proxy resolution (not the HTTP proxy - the old fashion authority
resolution proxy). 

The history: 

Without hierarchical XML, in the old days (ie CD-01) a client was simply
given the answer up to the point of the "redirect" and was expected to
follow the "redirect" (synonym/ref/term-of-the-day) itself. The proxy
wouldn't do it for you. 

Because we've done this HXRI proxy stuff, which implies that the proxy
will do *complete* resolution, we have had to define a more complete
behavior for proxies. In defining the more complete behavior for
proxies, somewhere along the line, it was decided that proxies (even
non-HXRI proxies) would do complete (ie following refs) resolution -
therefore proxies needed to be able to return the results of this
complete resolution - hence the need for the hierarchical results.

If we went back to CD-01 and said that normal authority proxies *don't*
follow refs, then we wouldn't need hiearchical results - except I spose
when an HXRI proxy is asked for the media type of XRDS? (I'm not even
sure then..)

	-Gabe

> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz] 
> Sent: Friday, January 27, 2006 12:43 AM
> To: Steven Churchill; Wachob, Gabe; 
> drummond.reed@cordance.net; xri@lists.oasis-open.org
> Cc: drummond.reed@gmail.com
> Subject: RE: [xri] Decision on Ref "backtracking" issue
> 
> Steve,
> 
> I agree with you that a server wishing to support lookahead resolution
> would probably use a resolver library to do the work, and that a
> no-follow-refs flag in the resolver client API would be very helpful.
> 
> IMHO the strongest use case for lookahead resolution is for a single
> server to be authoritative for multiple levels of authority to process
> lookahead requests. So, it makes sense for a server hosting =a*b and
> =a*b*c to answer for *b*c within a single round trip.
> 
> That is not to say that servers should not act as a client during
> lookahead resolution, but it adds complexity and duplicates the effort
> of following refs. In the case of trusted lookahead 
> resolution, does it
> mean that the server has to verify the SAML signatures once, and the
> client has to do the same once it receives the XRDS?
>  
> This seems like the classic argument of balancing the intelligence on
> the server vs the client. Putting more intelligence on the 
> server allows
> us to upgrade and deploy new services more easily but making 
> the server
> software more feature-rich also may mean more operational load. On the
> other hand, putting more intelligence on the client puts more 
> strain on
> the developers and possibly hider adoption.
> 
> Having said that, it is a good idea to have hierarchical XML
> standardized, I just don't know if it would ever make it over 
> the wire.
> I'm not fixated on getting rid of it, but wanted to make sure that we
> really need it; like Gabe, my complexity alarm is also flashing
> 
> wil. 
> 
> > -----Original Message-----
> > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > Sent: Thursday, January 26, 2006 6:18 AM
> > To: Tan, William; 'Wachob, Gabe'; drummond.reed@cordance.net;
> > xri@lists.oasis-open.org
> > Cc: drummond.reed@gmail.com
> > Subject: RE: [xri] Decision on Ref "backtracking" issue
> > 
> > 
> > 
> > Wil wrote:
> > 
> > > Should lookahead resolution really proceed to following Refs? I
> would
> > > prefer the server receiving the additional segments to stop at the
> point
> > > before it needs to follow a Ref and return the XRD's so far.
> > 
> > That seems like fine behavior for an Auth Res server. If I were the
> > server,
> > though, I would use the Resolver Client to perform lookahead
> resolution,
> > because the resolution behavior needs to be compliant with the
> Resolution
> > Spec (and who wants to implement the spec again?). So perhaps the
> Resolver
> > Client API needs a flag that tells it *not* to follow refs (to error
> out).
> > That way the Auth Res server can do the behavior you describe above.
> > 
> > > I still don't see a need for hierarchical XRDS to be 
> defined in the
> > > specs. IMO it adds complexity to, if not implementations, the
> > > specifications.
> > 
> > Again, the hierarchy is needed for Trusted resolution in order for a
> > client
> > to validate the trust chain. And for a client to do that, the format
> of
> > the
> > hierarchy needs to be explicit in the spec.
> > 
> > Perhaps Drummond can give his reasons why it's important also for
> Generic
> > resolution. (I feel that it should be there for Generic 
> resolution as
> > well,
> > but I'll admit that the reasons are not as compelling as the one for
> > Trusted
> > resolution.)
> > 
> > ~ Steve
> > 
> > 
> > > > -----Original Message-----
> > > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > > Sent: Wednesday, January 25, 2006 9:39 AM
> > > > To: Tan, William; 'Wachob, Gabe'; drummond.reed@cordance.net;
> > > > xri@lists.oasis-open.org
> > > > Cc: drummond.reed@gmail.com
> > > > Subject: RE: [xri] Decision on Ref "backtracking" issue
> > > >
> > > >
> > > > Wil,
> > > >
> > > > The proposal is that the hierarchical XML is compiled in the
> Resolver
> > > > client
> > > > (via recursion that is "abstracted out" of the 
> flowchart as per my
> > > > previously attached email.)
> > > >
> > > > The hierarchical XML would not be returned by an Authority
> Resolution
> > > > Services (except in the case of lookahead resolution where the
> Auth
> > > Res
> > > > Service is acting as a client.)
> > > >
> > > > I think the client resolver spec needs a MUST for the hierarchy,
> at
> > > least
> > > > for Trusted Resolution, because each of the signatures must be
> > > verified in
> > > > an inorder traversal of the tree. Whether or not it's a MUST for
> > > generic
> > > > resolution is a different story.
> > > >
> > > > Drummond, please chime in if I'm totally off base.
> > > >
> > > > ~ Steve
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tan, William [mailto:William.Tan@neustar.biz]
> > > > > Sent: Tuesday, January 24, 2006 12:50 PM
> > > > > To: Steven Churchill; Wachob, Gabe; 
> drummond.reed@cordance.net;
> > > > > xri@lists.oasis-open.org
> > > > > Cc: drummond.reed@gmail.com
> > > > > Subject: RE: [xri] Decision on Ref "backtracking" issue
> > > > >
> > > > > Steve,
> > > > >
> > > > > Do we really need hierarchical XML on the wire? It seems to me
> that
> > > this
> > > > > is only ever going to be composed by the resolver 
> library to the
> > > > > application, not between the authority server and the resolver
> > > library.
> > > > > Therefore, I'm arguing that we do need some way of 
> representing
> the
> > > > > final resolution result after having been through Ref
> processing,
> > > but it
> > > > > does not have to be standardized at the specifications; it is
> just
> > > an
> > > > > implementation issue e.g. a data structure exposed in the
> resolution
> > > API
> > > > > would do.
> > > > >
> > > > > Having missed out on the TC calls when you guys discussed the
> Ref
> > > stuff,
> > > > > I am sure there is a somewhat bigger picture or an 
> obvious point
> > > that
> > > > > I'm missing.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > wil.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > > > > Sent: Tuesday, January 24, 2006 6:20 AM
> > > > > > To: 'Wachob, Gabe'; drummond.reed@cordance.net;
> > > > > xri@lists.oasis-open.org
> > > > > > Cc: drummond.reed@gmail.com
> > > > > > Subject: RE: [xri] Decision on Ref "backtracking" issue
> > > > > >
> > > > > >
> > > > > >
> > > > > > Gabe,
> > > > > >
> > > > > > Yes a meta-error for this would be good.
> > > > > >
> > > > > > In my discussion in the previously attached email, the need
> for
> > > the
> > > > > stack
> > > > > > is
> > > > > > synonymous with the need for backtracking (unwinding). My
> point
> > > about
> > > > > the
> > > > > > backtracking was that it is needed for the hierarchical
> > > (bracketed)
> > > > > XML
> > > > > > output AS WELL AS for following sibling Refs.
> > > > > >
> > > > > > For reasons I discuss in that email(abstracting away the
> > > traversal), I
> > > > > > don't
> > > > > > feel backtracking adds complexity. (Put another way, we can
> have
> > > both
> > > > > the
> > > > > > sibling Ref traversal and the hierarchical XML 
> output without
> > > > > additional
> > > > > > complexity.)
> > > > > >
> > > > > > ~ Steve
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wachob, Gabe [mailto:gwachob@visa.com]
> > > > > > > Sent: Monday, January 23, 2006 1:46 PM
> > > > > > > To: Steven Churchill; drummond.reed@cordance.net;
> > > xri@lists.oasis-
> > > > > > open.org
> > > > > > > Cc: drummond.reed@gmail.com
> > > > > > > Subject: RE: [xri] Decision on Ref "backtracking" issue
> > > > > > >
> > > > > > > Steve-
> > > > > > > 	I understand the need for a stack. I still think that
> > > > > > > "backtracking" up that stack (er, down the stack, 
> depending
> on
> > > how
> > > > > you
> > > > > > > draw it) adds complexity - I'd rather say that if you get
> stuck
> > > > > > > somewhere, that you don't even bother unwinding 
> the stack to
> a
> > > > > decision
> > > > > > > point and try something else.
> > > > > > > 	But, I will defer to those implementing the spec to tell
> > > me
> > > > > > > whether this really adds complexity. One thing I know is
> that we
> > > > > might
> > > > > > > need to have a special error (was this mentioned before)
> that
> > > > > basically
> > > > > > > is "tried all ref's possible and had failures everwhere" -
> this
> > > is
> > > > > > > really a "meta-error" since the errors for each
> ref-traversal
> > > might
> > > > > be
> > > > > > > different.
> > > > > > >
> > > > > > > 	My complexity warning light is going off and I'm trying
> > > to
> > > > reset
> > > > > > > it... ;-)
> > > > > > >
> > > > > > > 	-Gabe
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > > > > > > Sent: Monday, January 23, 2006 1:21 PM
> > > > > > > > To: Wachob, Gabe; drummond.reed@cordance.net;
> > > > > xri@lists.oasis-open.org
> > > > > > > > Cc: drummond.reed@gmail.com
> > > > > > > > Subject: RE: [xri] Decision on Ref "backtracking" issue
> > > > > > > >
> > > > > > > >
> > > > > > > > Gabe,
> > > > > > > >
> > > > > > > > Backtracking is needed in any case, because it's needed
> for
> > > the
> > > > > XML
> > > > > > > > bracketing as well as for the following of sibling Refs.
> > > > > > > >
> > > > > > > > I've attached my previous email that talks about this in
> more
> > > > > detail.
> > > > > > > >
> > > > > > > > ~ Steve
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Wachob, Gabe [mailto:gwachob@visa.com]
> > > > > > > > > Sent: Monday, January 23, 2006 10:07 AM
> > > > > > > > > To: drummond.reed@cordance.net; 
> xri@lists.oasis-open.org
> > > > > > > > > Subject: RE: [xri] Decision on Ref 
> "backtracking" issue
> > > > > > > > >
> > > > > > > > > I'm not sure that the way #2 is specified, its any
> > > > > > > > different than #3.
> > > > > > > > >
> > > > > > > > > If I "try" a REF, and in resolving the 
> resulting XRI, I
> end
> > > > > > > > up with a
> > > > > > > > > set of REFS, am I required to try that set of 
> REFs that
> > > result
> > > > > from
> > > > > > > > > resolving the XRI I got from choosing the first REF?
> > > > > > > > >
> > > > > > > > > Specifically:
> > > > > > > > >
> > > > > > > > > Lets say =GabeW*coworker resolves to refs 
> that point to
> > > > > > > > =Mike and =Dave,
> > > > > > > > > and I choose =Mike and =Mike ends up with a ref to
> > > =SecretAgent
> > > > > and
> > > > > > > > > =PublicAgent.
> > > > > > > > >
> > > > > > > > > Lets say resolution of =SecretAgent fails.
> > > > > > > > >
> > > > > > > > > What do I do? Is that a failure that requires me to go
> back
> > > > > > > > to =Dave? Or
> > > > > > > > > should I try =PublicAgent? What happens if 
> =PublicAgent
> > > fails?
> > > > > > > > >
> > > > > > > > > Note that I think the wording of #2 and #3 
> both require
> me
> > > > > > > > to go back to
> > > > > > > > > =Dave is =SecretAgent and =PublicAgent fail. This is
> still
> > > > > > > > > backtracking... Right?
> > > > > > > > >
> > > > > > > > > 	-Gabe
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: drummond.reed@cordance.net
> > > > > > > > [mailto:drummond.reed@cordance.net]
> > > > > > > > > > Sent: Sunday, January 22, 2006 12:41 AM
> > > > > > > > > > To: xri@lists.oasis-open.org
> > > > > > > > > > Cc: drummond.reed@cordance.net
> > > > > > > > > > Subject: [xri] Decision on Ref "backtracking" issue
> > > > > > > > > >
> > > > > > > > > > First, for anyone unfamiliar with the Ref
> "backtracking"
> > > > > > > > issue in XRI
> > > > > > > > > > resolution, the question is where we draw 
> the line in
> > > terms
> > > > > > > > > > of required
> > > > > > > > > > behavior for a resolver when it comes to 
> following the
> > > XRIs
> > > > > > > > > > contained in
> > > > > > > > > > Ref elements (which I'll just call "Refs" in this
> > > message).
> > > > > > > > > >
> > > > > > > > > > Based on the discussion among the editors so far, it
> > > appears
> > > > > > > > > > we have three
> > > > > > > > > > choices:
> > > > > > > > > >
> > > > > > > > > > 1) Stop at the very first Ref in the current XRD and
> error
> > > if
> > > > > > > > > > it fails.
> > > > > > > > > >
> > > > > > > > > > 2) Try all Refs in the current XRD and error only if
> all
> > > > > > > > of them fail.
> > > > > > > > > >
> > > > > > > > > > 3) Try all Refs in the current XRD, and if they all
> fail,
> > > > > > > > > > then "backtrack"
> > > > > > > > > > to any previous XRDs and try all of them, 
> and only if
> they
> > > > > > > > > > ALL fail should
> > > > > > > > > > the resolver fail.
> > > > > > > > > >
> > > > > > > > > > Gabe has proposed that we not require #3, 
> since it is
> > > > > > > > both the most
> > > > > > > > > > complex and can take the most time. I agree.
> > > > > > > > > >
> > > > > > > > > > At the other end of the spectrum, Les' message below
> > > proposes
> > > > > > > > > > that we not
> > > > > > > > > > stop at #1, since there may be a good reason if the
> first
> > > Ref
> > > > > > > > > > in an XRD
> > > > > > > > > > doesn't work that the resolver should try 
> the others.
> > > > > > > > > >
> > > > > > > > > > So the proposal on the table now is to take a middle
> > > course
> > > > > > > > > > and require
> > > > > > > > > > only that if resolution of the first Ref in an XRD
> fails,
> > > > > > > > the resolver
> > > > > > > > > > must (subject to its own timeout 
> constraints) try the
> > > others
> > > > > > > > > > in priority
> > > > > > > > > > order, but it is NOT required for a resolver to
> > > "backtrack"
> > > > > > > > > > to previous
> > > > > > > > > > XRDs and try earlier "untried" Refs.
> > > > > > > > > >
> > > > > > > > > > Anyone who disagrees with this proposal, please send
> > > > > > > > email to the list
> > > > > > > > > > with an alternate (preferably by end of day 
> Monday USA
> --
> > > > > > > > > > silence will be
> > > > > > > > > > deemed consensus ;-)
> > > > > > > > > >
> > > > > > > > > > For reference, here's what the actual wording might
> look
> > > > > > > > > > something like:
> > > > > > > > > >
> > > > > > > > > > "If a client resolver is not able to find the
> requested
> > > > > > > > > > service endpoint
> > > > > > > > > > in the current XRD, or if the URI(s) for 
> that service
> > > > > > > > endpoint do not
> > > > > > > > > > produce a successful response, the client resolver
> MUST
> > > > > > > > > > (subject to its
> > > > > > > > > > own timeout constraints) attempt resolution of the
> highest
> > > > > > > > > > priority Ref of
> > > > > > > > > > the current XRD. If that resolution is 
> successful, the
> > > final
> > > > > > > > > > XRD of the
> > > > > > > > > > resulting XRDS document becomes the current XRD and
> > > > > > > > > > resolution continues.
> > > > > > > > > > If that resolution is not successful, the client
> resolver
> > > > > > > > MUST attempt
> > > > > > > > > > resolution of the next highest priority Ref of the
> current
> > > > > > > > > > XRD, and so on.
> > > > > > > > > > If resolution of all Refs in the current XRD fails,
> the
> > > > > > > > > > client resolver
> > > > > > > > > > MAY return an error 27, VALID_REF_NOT_FOUND, or the
> client
> > > > > > > > > > resolver MAY
> > > > > > > > > > "backtrack" to previous XRDs in the resolution chain
> and
> > > > > > > > > > attempt to follow
> > > > > > > > > > any untried Refs. Note that the latter 
> behavior is not
> > > > > > > > > > required and should
> > > > > > > > > > not be expected."
> > > > > > > > > >
> > > > > > > > > > =Drummond
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ----ORIGINAL MESSAGE FROM LES CHASEN------
> > > > > > > > > >
> > > > > > > > > > Do we really want to stop resolution if one REF is
> > > > > > > > > > unresponsive?  It seems
> > > > > > > > > > to me to be a good idea to have multiple authority
> > > services
> > > > > > > > > > (either via
> > > > > > > > > > SEPs, URIs or REFs) in case one is having a problem.
> It
> > > > > > > > > > seems to me the
> > > > > > > > > > resolver should do what ever it can, within 
> reason, to
> > > locate
> > > > > > > > > > the answer
> > > > > > > > > > for a request.  In DNS a domain can have upto 13
> > > nameservers.
> > > > > > > > > >  If one is
> > > > > > > > > > not responding for what ever reason the 
> resolver tries
> > > > > another.
> > > > > > > > > >
> > > > > > > > > > I-Name:  =les.chasen
> > > > > > > > > >
> > > > > > > > > >
> > > --------------------------------------------------------------
> > > > > > > > > > -------------
> > > > > > > > > >
> > > > > > > > > > From: Drummond Reed
> > > > > > > > > > Sent: Friday, January 20, 2006 11:33 AM
> > > > > > > > > > To: gwachob@visa.com; steven.churchill@ootao.com;
> Chasen,
> > > > > > > > > > Les; Tan, William
> > > > > > > > > > Cc: drummond.reed@cordance.net
> > > > > > > > > > Subject: Gabe's feedback and reference 
> "backtracking"
> > > > > > > > > >
> > > > > > > > > > Gabe and Res Editor's:
> > > > > > > > > >
> > > > > > > > > > Note that since I can only send from Gmail, I can't
> send
> > > this
> > > > > > > > > > to the list.
> > > > > > > > > > One of you is welcome to forward this to the list.
> > > > > > > > > >
> > > > > > > > > > I just went over Gabe's comments. Fantastic stuff.
> There's
> > > > > > > > > > many that we
> > > > > > > > > > need to go over (I *really* wish I could be on the
> call
> > > > > > > > > > Friday morning but
> > > > > > > > > > I gotta go to bed now...). Anyway, the 
> single biggest
> > > issue
> > > > > > > > > > is the one of
> > > > > > > > > > whether a resolver needs to do "backtracking" of
> > > references
> > > > > > > > > > (as currently
> > > > > > > > > > indicated in ED 04) or whether, as Gabe recommends,
> the
> > > > > > > > > > resolver should
> > > > > > > > > > just stop and report an error if it gets an error.
> > > > > > > > > >
> > > > > > > > > > I tend to agree with Gabe on this with one 
> exception:
> I
> > > think
> > > > > > > > > > that *within
> > > > > > > > > > a single service endpoint* if the resolver gets a
> network
> > > > > > > > > > error on one URI
> > > > > > > > > > and more then one URI is supplied, the 
> resolver should
> > > > > > > > try the next
> > > > > > > > > > highest priority URI, and so on. Same for the next
> > > > > > > > highest priority
> > > > > > > > > > service if there is >1 Service of that type in the
> XRD.
> > > > > > > > > >
> > > > > > > > > > But I agree with Gabe that if a resolver follows a
> > > reference
> > > > > > > > > > and hits an
> > > > > > > > > > error, it should not need to "backtrack" 
> but just stop
> > > > > > > > and report the
> > > > > > > > > > error.
> > > > > > > > > >
> > > > > > > > > > If everyone agrees to that on today's call, please
> > > > > > > > publish it in the
> > > > > > > > > > minutes and I'll update the flowcharts to match (and
> start
> > > > > > > > > > working on ED
> > > > > > > > > > 05 to make those changes.)
> > > > > > > > > >
> > > > > > > > > > All of Gabe's other comments made sense to 
> me. Please
> do
> > > > > > > > record in the
> > > > > > > > > > minutes any others that the editors have 
> consensus on
> and
> > > > > > > > I'll start
> > > > > > > > > > getting those into ED 05. I'd then like to 
> send it to
> > > > > > > > Gabe (or ???) to
> > > > > > > > > > take the pen and make whatever other changes we feel
> are
> > > > > > > > > > necessary before
> > > > > > > > > > publishing it as WD 10.
> > > > > > > > > >
> > > > > > > > > > =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_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
> > > > > >
> > > > > >
> > > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > 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_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 
> 
> 


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