Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

Sun Jun 5 06:13:12 CDT 2005

Hi Frank,

Thank you very much for your explanation. 
I think I get a picture now. 

You are proposing a resolve portType for Resilient Reference
resource which has no parameter. On the other hand, Mark is 
proposing a portType for generic resolver which has a parameter 
as an option (as shown in Figure 2). Your usecases and OGSA WSRF
BP 1.0 indicate the farmer is more reasonable.

Here, another question comes to my mind: if an abstract name is
rendered by EPR, could this abstract name have a resolve portType
with no parameter? I am just considering symmetry of both EPRs.

Talk to you on Monday at naming-WG-BoF call.
----
Hiro Kishimoto

> -----Original Message-----
> From: Frank Siebenlist [mailto:franks at mcs.anl.gov]
> Sent: Sunday, June 05, 2005 8:11 AM
> To: Hiro Kishimoto
> Cc: 'Mark Morgan'; 'Andrew Grimshaw'; ogsa-wg at ggf.org
> Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes
> uploaded)
> 
> Sorry Hiro, there must be a misunderstanding as I certainly do not want
> to prohibit a parameter for a resolution service as that will cater to a
> different set of use cases.
> 
> The RR-EPR can only be used in those use cases where the EPR
> creator/minter knows where it will update the resource's EPR in the case
> of changes. This allows the EPR-minter to create a resource-specific
> RR-EPR that points at a state element behind a resolver service that
> will hold the application's EPR.
> 
> However, in those cases where the EPR is created without the knowledge
> where the updated EPR will be stored exactly, then a generic resolver
> has to be used that has to be passed something-from or the-whole EPR as
> a parameter.
> 
> As far as I can tell, most EPR creators will normally know that they
> will have to cater for EPR changes, will know the resolver service that
> they will use to maintain the updated EPR, will therefor be able to
> create a RR-EPR, and will therefor be able to hide from the consumers of
> the EPR what name, what naming scheme or what convention is used for the
> RR=>EPR resolution.
> 
> So by having a Resilient Reference spec, we should be able to cater for
> the great majority of use cases where resource reference stability is an
> issue.
> 
> -Frank.
> 
> PS. In the good old days when all was simple, we had OGSI, GSHs and GSRs
> and life was good ;-) Conceptually, a GSH is a "name", a GSR is an EPR,
> and OGSI was very GSH/name centric: you always had a GSH, if you were
> lucky you had a GSH and a GSR, if you were a little less lucky you had a
> GSH and a resolver-GSR, and if you were out of luck you just had a GSH.
> In other words, you always had the standardized "name" already and
> therefor the resolver could be a generic service that expected the
> name=GSH as a parameter; there was no need for a RR-GSR to hide the use
> of the name/naming-scheme/convention.
> 
> 
> Hiro Kishimoto wrote:
> 
> >Hi Frank,
> >
> >I am not so sure if we have enough reasons to prohibit a parameter
> >for a resolution service.
> >
> >(1) In OGSI era, there is HandleResolver portType and findByHandle
> >operation has a target parameter.
> >
> >(2) Does your design cover all WS-addressing scenarios other than
> >WS-resource?
> >
> >Thanks,
> >----
> >Hiro Kishimoto
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Frank Siebenlist [mailto:franks at mcs.anl.gov]
> >>Sent: Saturday, June 04, 2005 3:39 PM
> >>To: Frank Siebenlist
> >>Cc: Mark Morgan; 'Andrew Grimshaw'; ogsa-wg at ggf.org; 'Hiro Kishimoto'
> >>Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes
> >>uploaded)
> >>
> >>Sorry, there was a confusing typo in my last email:
> >>s/different EPRs/different resources/
> >>
> >>For clarity I just restate my corrected message here:
> >>
> >>------
> >>
> >>The proposed "solution":
> >>
> >>
> >>
> >>>>the general idea we have
> >>>>is to in fact possibly have a method who's signature is
> >>>>EPR resolve( [EPR] )
> >>>>Where the parameter EPR is optional.
> >>>>
> >>>>
> >>>>
> >>shows to me that we still do not understand what those RRs do or are.
> >>
> >>An RR refers to a resolver service that doesn't expect an EPR as a
> >>parameter and wouldn't even know what to do with it, while a resolver
> >>that does expect an EPR as a parameter wouldn't know what to do if it
> >>didn't receive one - there is completely different semantics associated
> >>with the two use cases and overloading the interface to accommodate both
> >>is poor design.
> >>
> >>I'm sorry to bring some object-speak in here to make the point, but one
> >>could see the analogy where an RR is an object-reference where a message
> >>"resolve" will return a new reference, while the resolver-EPR is like a
> >>class-reference with a class/static-function that needs an EPR/name to
> >>return a reference. If you have the idea that you could reuse the
> >>resolver-EPR to resolve many different names/EPRs pointing at different
> >>RESOURCES, while the RR is truly tied to a single "resource", then you
> >>have the right picture.
> >>
> >>-Frank.
> >>
> >>----------------------------------------------------
> >>
> >>
> >>
> >>Frank Siebenlist wrote:
> >>
> >>
> >>
> >>>The proposed "solution":
> >>>
> >>>
> >>>
> >>>>the general idea we have
> >>>>is to in fact possibly have a method who's signature is
> >>>>EPR resolve( [EPR] )
> >>>>Where the parameter EPR is optional.
> >>>>
> >>>>
> >>>>
> >>>shows to me that we still do not understand what those RRs do or are.
> >>>
> >>>An RR refers to a resolver service that doesn't expect an EPR as a
> >>>parameter and wouldn't even know what to do with it, while a resolver
> >>>that does expect an EPR as a parameter wouldn't know what to do if it
> >>>didn't receive one - there is completely different semantics associated
> >>>with the two use cases and overloading the interface to accomodate both
> >>>is poor design.
> >>>
> >>>I'm sorry to bring some object-speak in here to make the point, but one
> >>>could see the analogy where an RR is an object-reference where a message
> >>>"resolve" will return a new reference, while the resolver-epr is like a
> >>>class-reference with a class/static-function that needs an epr/name to
> >>>return a reference. If you have the idea that you could reuse the
> >>>resolver-epr to resolve many different EPRs pointing at different EPRs,
> >>>while the RR is truly tied to a single "resource", then you have the
> >>>right picture.
> >>>
> >>>-Frank.
> >>>
> >>>
> >>>
> >>>Mark Morgan wrote:
> >>>
> >>>
> >>>
> >>>>The following secion is copied directly from the WSRF Base Profile
> >>>>document
> >>>>submitted to Grid Forge on 22 May 2005
> >>>>
> >>>>"
> >>>>3.1.2 Resilient Endpoint References
> >>>>
> >>>>WS-Addressing does not provide a normative mechanism for creating
> >>>>resilient
> >>>>endpoint references: i.e., an endpoint reference that can be
> >>>>"renewed" from
> >>>>some source when it becomes invalid. An OGSA service may require a
> >>>>resilient
> >>>>endpoint reference. To accomplish this, resiliency metadata MAY be
> >>>>included
> >>>>in an endpoint reference.
> >>>>
> >>>>R0305 An ENDPOINTREFERENCE MAY contain zero or more
> >>>>ogsa-bp:resilientReference extensibility elements from the
> >>>>http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0 namespace to
> >>>>specify the endpoint reference for a reference resolution service.
> >>>>
> >>>>R0307 A reference resolution INSTANCE MUST support the ogsa-rns:Resolve
> >>>>message exchange to allow for the re-resolution of the endpoint
> >>>>reference.
> >>>>
> >>>>R0308 A CONSUMER of an endpoint reference that contains an
> >>>>ogsa-bp:resilientReference extensibility element SHOULD send an
> >>>>ogsa-rr:Resolve message exchange to the ogsa-bp:resilientReference in
> >>>>response to a wsrf-rap:ResourceUnknownFault.
> >>>>"
> >>>>
> >>>>This particular section refers to a message exchange defined inside
> >>>>of the
> >>>>RNS spec which coincidentally infact passes an abstract name as it's
> >>>>parameter. However, a phone conversation with Tom Maguire informs me that
> >>>>this is legacy text which wasn't updated due to the conversation in
> >>>>London.
> >>>>The intended result is to have a message exchange where the caller didn't
> >>>>have to know about Abstract names. In essence, a message exchange
> >>>>which was
> >>>>empty as far as parameters go and for which all relevant information was
> >>>>contained in reference properties/parameters.
> >>>>
> >>>>This section describes the resolution protocols that "would" have been in
> >>>>place in the base profile had we not decided at the London face to face
> >>>>meeting that it was unnecessary to do so given that the naming group
> >>>>could
> >>>>make a small modification and satisfy the requirements. To recap, the
> >>>>discussion was that if Andrew and myself could come up with a resolution
> >>>>protocol that worked with WS-Naming that satisfied the requirement of not
> >>>>requiring an abstract name, then there was no reason to put it in the
> >>>>Base
> >>>>Profile.
> >>>>
> >>>>Here is technically some reasons why.
> >>>>
> >>>>First, if we look at the section described by the old Base Profile that I
> >>>>pasted above, one can extrapolate a "possible" EPR and "possible" message
> >>>>exchange for this particular form of resolution. Here is one way it might
> >>>>look (note, I assume a particular version of WS-Addressing, but concepts
> >>>>remain unchanged as versions of Addressing change):
> >>>>
> >>>>// Possible EPR
> >>>><wsa:SomeEPR>
> >>>><wsa:To>http://www.some.url/some-path/some-service</wsa:To>
> >>>><wsa:ReferenceParameters>
> >>>><SomeOpaqueData>...</SomeOpaqueData>
> >>>></wsa:ReferenceParameters>
> >>>><wsa:metadata>
> >>>><ogsa-bp:resilientReference
> >>>>xmlns:ogsa-bp="http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-
> 1.0">
> >>>>
> >>>><wsa:To>http://www.some-other.url/some-other-path/some-other-
> >>>>
> >>>>
> >>service</wsa:To
> >>
> >>
> >>>><wsa:ReferenceParameters>
> >>>><SomeOpaqueData>...</SomeOpaqueData>
> >>>></wsa:ReferenceParameters>
> >>>><wsa:metadata>
> >>>>"etc...."
> >>>></wsa:metadata>
> >>>></ogsa-bp:resilientReference>
> >>>></wsa:metadata>
> >>>></wsa:SomeEPR>
> >>>>
> >>>>// Possible resolution message
> >>>><soap:Body>
> >>>><ogsa-bp:resolve
> >>>>xmlns:ogsa-bp="http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-
> >>>>
> >>>>
> >>1.0"/>
> >>
> >>
> >>>></soap:Body>
> >>>>
> >>>>Now, for the sake of discussion, I attach a handful of sections and
> >>>>slides
> >>>>
> >>>>
> >>>>from WS-Naming documents that are relevant:
> >>>
> >>>
> >>>
> >>>>"
> >>>>The process for adding a resolver to an existing EPR is analogously
> >>>>simple
> >>>>to that of adding an Abstract Name. A new element called
> >>>>ReferenceResolver
> >>>>is added to the Endpoint Reference Type of any service endpoint which
> >>>>supports the WS-Naming profile. This element is itself an Endpoint
> >>>>Reference Type and can be as arbitrarily simple (Figure 3) or complex
> >>>>(Figure 4) as desired.
> >>>>"
> >>>>
> >>>>"
> >>>>Figure 3:
> >>>><wsa:EndpointReference
> >>>>xmlns:wsa="http://www.w3.org/2005/02/addressing"
> >>>>xmlns:name="http://tempuri.org/">
> >>>><wsa:Address>http://tempuri.org/example</wsa:Address>
> >>>><wsa:Policies>
> >>>>
> >>>><name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-
> >>>>
> >>>>
> >>39DFB8B54388</name:Abstr
> >>
> >>
> >>>>actName>
> >>>>
> >>>><name:ReferenceResolver>
> >>>>
> >>>><wsa:Address>http://tempuri.org/resolver1</wsa:Address>
> >>>></name:ReferenceResolver>
> >>>></wsa:Policies>
> >>>></wsa:EndpointReference>
> >>>>"
> >>>>
> >>>>"
> >>>>Figure 4:
> >>>><wsa:EndpointReference
> >>>>xmlns:wsa="http://www.w3.org/2005/02/addressing"
> >>>>xmlns:name="http://tempuri.org/">
> >>>><wsa:Address>http://tempuri.org/example</wsa:Address>
> >>>><wsa:Policies>
> >>>>
> >>>><name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-
> >>>>
> >>>>
> >>39DFB8B54388</name:Abstr
> >>
> >>
> >>>>actName>
> >>>>
> >>>><name:ReferenceResolver>
> >>>>
> >>>><wsa:Address>http://tempuri.org/resolver1</wsa:Address>
> >>>><wsa:ReferenceParameters>
> >>>>guid:8733111B-84FA-4da8-89FE-417932B3B92C
> >>>></wsa:ReferenceParameters>
> >>>><wsa:Policies>
> >>>>
> >>>><name:AbstractName>urn:guid:55AD06F6-2F35-409a-9DCE-
> >>>>
> >>>>
> >>E5F304E557AA</name:Abstr
> >>
> >>
> >>>>actName>
> >>>><name:ReferenceResolver>
> >>>>
> >>>><wsa:Address>http://tempuri.org/resolve2</wsa:Address>
> >>>></name:ReferenceResolver>
> >>>></wsa:Policies>
> >>>></name:ReferenceResolver>
> >>>></wsa:Policies>
> >>>></wsa:EndpointReference>
> >>>>"
> >>>>
> >>>>And finally, here are the two, "original" methods from the Naming
> >>>>document:
> >>>>EPR resolve(AbstractName)
> >>>>EPR resolve(EPR)
> >>>>
> >>>>Based on the discussion and agreements reached in London, Andrew and
> >>>>I were
> >>>>to come up with resolution that didn't require a parameter. The
> >>>>discussion
> >>>>on this will happen at the next Naming telecon, but the general idea
> >>>>we have
> >>>>is to in fact possibly have a method who's signature is
> >>>>EPR resolve( [EPR] )
> >>>>Where the parameter EPR is optional. If this were to be the case, a
> >>>>possible message for resolution would be:
> >>>>
> >>>>// Possible resolution message
> >>>><soap:Body>
> >>>><ws-naming:resolve
> >>>>xmlns:ws-naming="http://some-appropriate-namespace"/>
> >>>></soap:Body>
> >>>>
> >>>>First of all, if we look back at the original resolution message from the
> >>>>base profile case, we see that there is absolutely nothing WSRF-like
> >>>>about
> >>>>it. That begs the question why such a thing would go into the WSRF Base
> >>>>Profile. Putting it there nearly guarantees that any OGSA profile
> >>>>will have
> >>>>to redefine another resolution exchange that will look idential, but
> >>>>which
> >>>>will occur in different namespaces, thereby breaking a point of
> >>>>interoperability that didn't have to be broken. By moving it into the
> >>>>naming group, which exists outside of any profile, interoperability
> >>>>is much
> >>>>more likely and possible.
> >>>>
> >>>>Further, the only difference between the two messages that are in
> >>>>this email
> >>>>is the namespace -- clearly this would indicate that the naming group is
> >>>>capable of satisfying all of the requirements that the profile has
> >>>>technically. In fact, if you compare the corresponding pieces side by
> >>>>side,
> >>>>the only real difference between what is in the OGSA Base Profile,
> >>>>and what
> >>>>is in the naming group is that the naming group allows for a slightly
> >>>>broader interpretation of the bits without requiring that broader
> >>>>view. In
> >>>>otherwords, everything in the base profile is a subset of naming as
> >>>>already
> >>>>written down in documents or proposed on email. Just as in the case with
> >>>>the Base Profile stuff, the information in WS-Naming is optional to
> >>>>implementors as well.
> >>>>
> >>>>A direct comparison of Base Profile Resolution and WS-Naming Resolution
> >>>>
> >>>>Base Profile Resolution WS-Naming Resolution
> >>>>----------------------- --------------------
> >>>>* Any given EPR may have a * Exactly the same
> >>>>piece of metadata which is
> >>>>itself an EPR representing
> >>>>a resolver service. Nothing
> >>>>prevents this resolver EPR from
> >>>>also having it's own resolver EPR
> >>>>contained therein, and etc.
> >>>>* The resolver service must implement a * The resolver service will
> >>>>either
> >>>>message exchange which effectively be required to implement a message
> >>>>satisfies the function signature: excahnge for the
> >>>>interface:
> >>>>EPR resolve() EPR resolve( [EPR] )
> >>>>or it will be
> >>>>required to implement both:
> >>>>EPR resolve(
> >>>>[EPR] )
> >>>>EPR resolve(
> >>>>AbstractName )
> >>>>or some set that
> >>>>is functionally equivalent
> >>>>
> >>>>These are the two pieces of resolution in both cases and the seem pretty
> >>>>much equivalent.
> >>>>
> >>>>-Mark
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
> >>>>>Behalf Of Andrew Grimshaw
> >>>>>Sent: Friday, June 03, 2005 1:00 PM
> >>>>>To: 'Frank Siebenlist'; ogsa-wg at ggf.org
> >>>>>Cc: 'Hiro Kishimoto'
> >>>>>Subject: RE: Resilient References? (Re: [ogsa-wg] ogsa London
> >>>>>f2f minutes uploaded)
> >>>>>
> >>>>>Frank et. Al.
> >>>>>Let me begin by saying that I believe there are two basic
> >>>>>arguments for keeping resolution out of the base profile and
> >>>>>in WS-Naming (really the WS-Name Resolution component): 1)
> >>>>>architectural cleanliness and politics, and 2) purely
> >>>>>technical. Mark Morgan will address (2) in a subsequent email.
> >>>>>I will address (1).
> >>>>>
> >>>>>Architectural cleanliness and politics.
> >>>>>Let's take the architectural issue first.
> >>>>>
> >>>>>What we are taking about is naming and name resolution
> >>>>>including rebinding of existing bindings. Here a binding is
> >>>>>some sort of <address, way to identify the thing the binding
> >>>>>is for> tuple. Multi-layer schemes for this are as old as
> >>>>>Moses in distributed systems - and even in regular operating
> >>>>>systems and programming languages (think swizzle).
> >>>>>
> >>>>>Now, suppose that we have a mechanism in WSRF-Base Profile
> >>>>>for doing the rebinding as proposed, i.e,
> >>>>>ogsa-bp:resilientReference
> >>>>>ogsa-rns:Resolve
> >>>>>
> >>>>>Later, a different OGSA base profile, perhaps for WSI, comes
> >>>>>along and they also need a resolution scheme. So we have
> >>>>>another set of names/namespaces for doing EXACTLY the same thing.
> >>>>>
> >>>>>OR, a basic WS facility, endorsed by many major players,
> >>>>>comes along that also does resolution ... and we yet another
> >>>>>way of doing the same thing.
> >>>>>
> >>>>>It is, in my opinion, much better to do resolution ONCE,
> >>>>>along with other naming and name resolution, and in such a
> >>>>>way as to be completely INDEPENDENT of grid. Why independent
> >>>>>of grid? Because we want a system that will be as ubiquitous
> >>>>>as possible - and used for both "grid services" and more
> >>>>>general "web services".
> >>>>>
> >>>>>Now to politics. If we assume for the moment that a) naming
> >>>>>and binding has broader impact than just grids, and b) we are
> >>>>>striving for wide-spread usage, then it is very important
> >>>>>that all of the major vendors are willing to "buy in" to
> >>>>>whatever scheme we come up with. The reality right now is
> >>>>>that some vendors will not touch anything associated with
> >>>>>WSRF. Yet your proposal will be in the WSRF-Base-Profile!
> >>>>>
> >>>>>As I mentioned earlier Mark will address some of the more
> >>>>>technical issues.
> >>>>>I'll steal some of his thunder and point out that the current
> >>>>>proposal in WS-Naming clearly separates "naming" from
> >>>>>"resolution". Indeed, once could resolve an EPR that does
> >>>>>not contain an abstract name.
> >>>>>
> >>>>>Andrew
> >>>>>
> >>>>>Ps. Below I comment on some of your specific points, with
> >>>>><AG> .. </AG> tags.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
> >>>>>Behalf Of Frank Siebenlist
> >>>>>Sent: Wednesday, June 01, 2005 8:55 PM
> >>>>>To: ogsa-wg at ggf.org
> >>>>>Cc: Hiro Kishimoto
> >>>>>Subject: Re: Resilient References? (Re: [ogsa-wg] ogsa London
> >>>>>f2f minutes
> >>>>>uploaded)
> >>>>>
> >>>>>Let me try to argue one more time about NOT including the
> >>>>>resilient reference spec in the ws-naming.
> >>>>>
> >>>>>First of all, this resilient reference (RR) is not dependent
> >>>>>on any naming scheme; not on any notion of what an identity
> >>>>>is, may be or smells like: no name is "visible" to the
> >>>>>consumer of the RR's EPR as all is hidden inside of that EPR.
> >>>>>
> >>>>><AG> This is the case in the proposed WS-Naming scheme as
> >>>>>well, the consumer does not have to look at the AbstractName
> >>>>>if there is one - and indeed with the modifications based on
> >>>>>Tom's feedback, there need not be an AbstractName at all. </AG>
> >>>>>
> >>>>>The interface has no input message parameter, is extremely
> >>>>>simple and easy to implement - the code that would deal with
> >>>>>those RRs would be fairly straightforward and would provide
> >>>>>clients with that extra stability that will allow them to
> >>>>>connect with those resources that may move, or may listen on
> >>>>>other ports, or bound to a different protocol, whatever...
> >>>>>
> >>>>><AG> Dito </AG>
> >>>>>
> >>>>>
> >>>>>In other words, it is a thing or rare beauty and an
> >>>>>abstraction you don't find often.
> >>>>>
> >>>>><AG> Dito </AG>
> >>>>>
> >>>>>Now the cons of adding this to the ws-naming are:
> >>>>>
> >>>>>* all naming discussions that I've been part of get bugged
> >>>>>down in religious discussions about what names are, what
> >>>>>identities are, whether we need them, what their formats are
> >>>>>or should be or should not be, whether we should use URIs or
> >>>>>should not, how many naming levels we need, what interfaces
> >>>>>we will have for resolutions and what parameters will be
> >>>>>passed - none of this is trivial and it will take time for
> >>>>>all to agree ... and it is very possible that not all will agree...
> >>>>>
> >>>>><AG> First, as I said above AbstractNames and resolution are separate.
> >>>>>Second, one of the nice things about AbstractNames is they
> >>>>>are just strings.
> >>>>>Interpretation is up to the generator of the names, they need
> >>>>>no parsing.
> >>>>></AG>
> >>>>>
> >>>>>* ...and the most important thing is that there will also be
> >>>>>the notion of "ws-naming" compliance that is needed for
> >>>>>interoperability, which brings up another complicated
> >>>>>discussion of what subset of ws-naming needs a MUST or a SHOULD...
> >>>>>
> >>>>>Note that the RRs are very useful stand-alone, without any of
> >>>>>the additional naming features, bells and whistles.
> >>>>><AG> See my above comments on cleanliness and politics. </AG>
> >>>>>
> >>>>>So in order to keep the RRs save and allow for adoption of
> >>>>>RRs, we would then need a ws-naming "level-0 compliance" that
> >>>>>would allow implementers to adopt the RRs without the rest of
> >>>>>ws-naming. Higher level compliances would then deal with the
> >>>>>actual use of names, naming conventions and such.
> >>>>>
> >>>>>That last observation could also lead to a decision to split
> >>>>>the charter of ws-naming in two. The first part would deal
> >>>>>with RRs only and could most probably be decided quickly with
> >>>>>a separate, very short spec, while the second part of the
> >>>>>charter would deal with the more complicated matter that
> >>>>>involves the visible names. I can imagine that MS would be
> >>>>>very much in favor of such a pragmatic approach.
> >>>>>
> >>>>>-Frank.
> >>>>>
> >>>>>PS. Please note that I am very interested in ws-naming and
> >>>>>truly hope that useful things will come out of it, but for
> >>>>>the reasons stated I would like to save this little RR-gem
> >>>>>
> >>>>>
> >>>>>from unnecessary delays and adoption hurdles such that it
> >>>>
> >>>>
> >>>>
> >>>>>could actually be deployed.
> >>>>>
> >>>>>
> >>>>>Frank Siebenlist wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I've been reading the minutes and was wondering if anything
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>was decided
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>about those Resilient References.
> >>>>>>
> >>>>>>Personally I hope it is still in the BP as it seems
> >>>>>>independent/stays-clear of any of the naming issues.
> >>>>>>
> >>>>>>In other words, this seems low hanging fruit and moving it in the
> >>>>>>naming profile could delay adoption (unless anyone can tell
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>me that all
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the naming will be resolved next week ;-) ).
> >>>>>>
> >>>>>>-Frank.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Hiro Kishimoto wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Hi all,
> >>>>>>>
> >>>>>>>Mark and Andreas upload F2F minutes to GridForge.
> >>>>>>>Please have a look and approve them tomorrow.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>They are now online:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>https://forge.gridforum.org/projects/ogsa-wg/document/f2f-mi
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>nutes-2005
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>0524
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>/en/1
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>https://forge.gridforum.org/projects/ogsa-wg/document/f2f-mi
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>nutes-2005
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>0523
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>/en/1
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>Thanks Mark and Andreas for your excellent minutes!
> >>>>>>>----
> >>>>>>>Hiro Kishimoto
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>--
> >>>>>Frank Siebenlist franks at mcs.anl.gov
> >>>>>The Globus Alliance - Argonne National Laboratory
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>--
> >>Frank Siebenlist franks at mcs.anl.gov
> >>The Globus Alliance - Argonne National Laboratory
> >>
> >>
> >
> >
> >
> >
> 
> --
> Frank Siebenlist               franks at mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
> 