I think we have gotten ourselves a little confused here.
The way I see the issue: this is not a question of WS-Transfer vs. WSRF,
etc.--the point being raised is (as I initially said):
"He [Peter] advocates (I believe) that we should not include the
GetAttributesDocument operation in BES. Instead, any particular BES
should choose (if they wish) to provide access to attributes via
appropriate operation(s).
* A WS-Transfer-based BES would use GET
* A WSRF-based BES would use WS-ResourceProperties
* A resource-model-free BES might define a GetAttributesDocument
operation
* etc."
The point being that if we have GetAttributesDocument in BES, then anyone
implementing a WS-Transfer-based version of BES will end up with two
operations, Get and GetAttributesDocument, that basically do the same
thing. Similarly for WSRF. Not fatal, but arguably rather
inelegant.
Ian.
At 02:26 PM 9/6/2006 -0400, Maguire_Tom@emc.com wrote:
Content-class:
urn:content-classes:message
Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_0063_01C6D1C0.5FDDB850"
But the only reason we were resource agnostic was because there was
conflict. We didn't choose to be resource agnostic just because it
seemed
like a good idea (did we?). There certainly was (are) some who
argue
against any resource model (eg. Purely stateless services), vs those
who
would encode some resource identity into an addressing scheme (WS-RF
and
WS-Transfer). In the end most (all) of this discussion is about
whether we
should encode identity of state in parameters in the body of the request
or
we should encode identity of state in the headers not whether there is
state
or not.
Personally, I think that WS-Addressing makes all of this pretty moot, but
if
shouting at the wind makes us feel better, feel free....
Tom
_______________________________________________
Tom Maguire
+1(845) 729-4806
-----Original Message-----
From: ogsa-bes-wg-bounces@ogf.org
[mailto:ogsa-bes-wg-bounces@ogf.org]
On
Behalf Of Andrew Grimshaw
Sent: Wednesday, September 06, 2006 1:48 PM
To: 'Mail list for ogsa-bes-wg working group'
Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
I agree with Chris - I never thought of this as a WS-RF versus anything
else
issue - more an issue with trying to be resource model
agnostic.
A
> -----Original Message-----
> From: ogsa-bes-wg-bounces@ogf.org
[mailto:ogsa-bes-wg-bounces@ogf.org]
> On Behalf Of Christopher Smith
> Sent: Wednesday, September 06, 2006 1:17 PM
> To: Mail list for ogsa-bes-wg working group
> Cc: ogsa-bes-wg@ggf.org
> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions
>
> Characterizing this issue as WS-RF vs WS-Transfer is misleading. I
can't
> recall any discussions within this group where anybody advocated
doing a
> WS-Transfer rendering for the BES interface. Well ... other than the
WS-
> RF
> proponents who wrongly assumed that because some (like myself)
were
> against
> the use of WS-RF, that must mean we were in favour of WS-Transfer.
I
> also
> don't recall anybody advocating operations for modification, etc
such as
> defined within WS-Transfer. To me this is a discussion of a
resource
> modelling approach (built on WS-RF) vs a non resource modelling
approach.
>
> My main reason for not wanting to make use of one of the
resource
> modelling
> approaches has to do with the burden of implementation. If Platform
buys
> into one of these resource models, we no longer have to implement
one
> simple
> spec and test compliance of that specification, but we need to
implement
> and
> test compliance on a suite of specifications, for (in my opinion)
no
> extra
> benefit. You might say that once you've implemented a resource
modelling
> suite of specifications, you can use it over and over and thus
amortize
> the
> cost of this implementation. But even at a small cost, it's not one
that
> I'm
> willing to take, as the implementation of standards specifications
is
> one
> feature in a sea of features that we implement from product release
to
> product release.
>
> -- Chris
>
>
>
> On 06/9/06 07:56, "Peter G. Lane" <lane@mcs.anl.gov>
wrote:
>
> > If it's about fear of reopening the dialog, then I'd appreciate
if
> someone
> > could at least add
> > comments to the two trackers addressing the issues
raised.
> >
> > Ian can push for reopening this particular issue if he wants;
but I
> just want
> > to know why we're
> > advocating WS-Transfer in spirit if not in name, and why
aggregation
> of
> > resource attributes is not a
> > concern to anyone else. As long as someone has a reason for
these
> issues that
> > I raised in the
> > tracker, I'm fine. I don't expect to get everything to go my
way, and
> I'm open
> > to being convinced of
> > alternate points of view. I just don't like being ignorant,
especially
> when
> > I'll have to implement
> > the spec someday.
> >
> > On the other hand, if nobody has a good answer for the issues,
I think
> Ian is
> > perfectly valid in
> > asking for it to be reopened as apparently the issues weren't
actually
> > addressed as they should have
> > been.
> >
> > Peter
> >
> > Mark Morgan wrote:
> >> Well, I guess the thing that confuses me is whether or not
it is SOP
> to
> >> re-open an issue that was discussed previously because a
new person
> has
> >> re-raised that issue. I'll bow to whatever the
majority thinks is
> best of
> >> course, but it seems to me that you can't reopen an issue
everytime a
> new
> >> person re-raises it or you risk the possibility of
continuously
> cycling on
> >> it. New information should always be considered, but
if an issue
> gets
> >> re-raised that has already been discussed fully and voted
on, then it
> >> doesn't make sense to re-discuss it. Just my 2 cents
worth...
> >>
> >> -Mark
> >>
> >>> -----Original Message-----
> >>> From: ogsa-bes-wg-bounces@ogf.org
> >>>
[mailto:ogsa-bes-wg-bounces@ogf.org]
On Behalf Of Ian Foster
> >>> Sent: Tuesday, September 05, 2006 9:39 PM
> >>> To: Mail list for ogsa-bes-wg working group; 'Mail list
for
> >>> ogsa-bes-wg working group'; ogsa-bes-wg@ggf.org
> >>> Subject: Re: [OGSA-BES-WG] Tracker Resolution
Descriptions
> >>>
> >>> Mark:
> >>>
> >>> I guess that I am asking that we re-open the issue,
then.
> >>>
> >>> Ian.
> >>>
> >>> At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote:
> >>>
> >>>
> >>> I'm not sure what level of "addressing" is
meant here, but my
> >>> recollection/belief was that it was addressed in
the
> >>> group in so much as the
> >>> topic was discussed at the last face-to-face and
that
> >>> the appearance of the
> >>> GetAttributesDocument was the result of that
> >>> discussion. We haven't as a
> >>> group discussed the email that Peter sent out yet
but
> >>> it is my belief that
> >>> doing so is essentially a rehash of discussions
previously had.
> >>>
> >>> -Mark
> >>>
> >>>> -----Original Message-----
> >>>> From: ogsa-bes-wg-bounces@ogf.org
> >>>>
[mailto:ogsa-bes-wg-bounces@ogf.org]
On Behalf Of Ian Foster
> >>>> Sent: Tuesday, September 05, 2006 1:42 PM
> >>>> To: Mail list for ogsa-bes-wg working group;
> >>> ogsa-bes-wg@ggf.org
> >>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution
Descriptions
> >>>>
> >>>> Has Peter's comment been discussed?
> >>>>
> >>>> He advocates (I believe) that we should not include
the
> >>>> GetAttributesDocument operation. Instead, any
particular BES
> >>>> should choose (if they wish) to provide access to
attributes
> >>>> via an appropriate resource model-specific
operations.
> >>>>
> >>>> * A WS-Transfer-based BES would use GET
> >>>> * A WSRF-based BES would use
WS-ResourceProperties
> >>>> * A resource-model-free BES might define a
> >>>> GetAttributesDocument operation
> >>>> * etc.
> >>>>
> >>>> This seems a good proposal to me.
> >>>>
> >>>> Ian.
> >>>>
> >>>> At 03:09 PM 9/2/2006 -0600, Peter G. Lane
wrote:
> >>>>
> >>>>
> >>>> 2) Why are we
still essentially advocating
> >>>> WS-Transfer's attribute model by having the
> >>>> GetAttributesDocument operation? In my opinion it
is not
> >>>> necessary for minimal interop, and makes
WS-Transfer's Get
> >>>> operation redundant. Is part of the problem that we
haven't
> >>>> defined any interop standards yet?
> >>>>
> >>>>
> >>>
_______________________________________________________________
> >>>> Ian Foster -- Weblog:
http://ianfoster.typepad.com
> >>>
<http://ianfoster.typepad.com/>
> >>>>
<http://ianfoster.typepad.com/>
Computation Institute:
> >>>>
www.ci.uchicago.edu
<http://www.ci.uchicago.edu/>
> >>> <http://www.ci.uchicago.edu/> &
> >>>> www.ci.anl.gov <http://www.ci.anl.gov/>
> >>> <http://www.ci.anl.gov/>
> >>>> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
> >>>> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
> >>>> Tel: +1 630 252 4619 --- Globus Alliance:
> >>> www.globus.org <http://www.globus.org/>
> >>>> <http://www.globus.org/>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> ogsa-bes-wg mailing list
> >>> ogsa-bes-wg@ogf.org
> >>> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
> >>>
> >>> _______________________________________________________________
> >>> Ian Foster -- Weblog: http://ianfoster.typepad.com
> >>> <http://ianfoster.typepad.com/> Computation Institute:
> >>> www.ci.uchicago.edu <http://www.ci.uchicago.edu/> &
> >>> www.ci.anl.gov <http://www.ci.anl.gov/>
> >>> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
> >>> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
> >>> Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
> >>> <http://www.globus.org/>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> ogsa-bes-wg mailing list
> >> ogsa-bes-wg@ogf.org
> >> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
> >>
> >
> > --
> > ogsa-bes-wg mailing list
> > ogsa-bes-wg@ogf.org
> > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>
> --
> ogsa-bes-wg mailing list
> ogsa-bes-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
--
ogsa-bes-wg mailing list
ogsa-bes-wg@ogf.org
http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Disposition: attachment;
filename="smime.p7s"
0 *H
010 +0 *H
0=0ͺVT"rU0
*H
0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0
960129000000Z
280801235959Z0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00
*H
0mVa-Hqg뷞 8%Fs $]
enVsߴX9knը?144g NEVixG)6c\-{2{0*/1g0
*H
L?hC3]˄Mz36ؕ"6hl|B.?OvJ )"]݁#{%F0yK@<_SH䆴{5{%ӎ?84q0b0 ? tz.30
*H
0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0
980512000000Z
080512235959Z010UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00
*H
0ZDUz-Ox6
JoTw*h1ApzKHV-BD\B/;' ]6B3nTOJ臶ƚj$e~7jJ 䙣00U00GU@0>0<`HE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HB0
*H
}oEK8 Sd!L+@ 9j2!,Yb}U87sfcbSpRR[-Ϭ1Tԋ#+2},|.wDe MtӒst.;5r@1ӲīV00 aIthSȬ1 .0
*H
010UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0
060419000000Z
070419235959Z010UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H
maguire_tom@emc.com00
*H
0O! cu!_FWny>ϼ$"eqߩtK?@K[REH#S1w\la7)_e66$sxT4˪/磁00 U00DU=0;09`HE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0
*H
<A'T$<܄{nDa6gWؿɨOEq!nw) 曃5ܛʣeFD()̇L4ńA,^56ӰoIA1>0:0010UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaIthSȬ1 .0 + 0 *H
1 *H
0 *H
1
060906182559Z0# *H
1j._V0g *H
1Z0X0 *H
0*H
0
*H
@0+0
*H
(0+0 *H
0 +710010UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaIthSȬ1 .0*H
1 010UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaIthSȬ1 .0
*H
6K?ܦW]1VzW`=B䬇R/ >H+ANܸߊϩsթJHs´k\=`1ԅUok?vpD|)!1#ٍ15
--
ogsa-bes-wg mailing list
ogsa-bes-wg@ogf.org
http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com
Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org