Re: [OGSA-BES-WG] Tracker Resolution Descriptions
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¦ÍºVðßä¼Tþ"¬³rªU0 *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÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fås¨ $] Ìen°ÐV¡sß´X9knÁöÕ¨¨?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?¸ÆhßîC3]é¦ËMz3ÿô6Ø"6hl|BÌó.Ä?°Oÿvùâ¼JéÍ ÷Å)ñ"]¸±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHä´{¡5°{%º¸Ó«?84óÑq0b0Ë ÚÁ?« tz´Î.30 *H÷ 0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10UVeriSign, 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÷ 0»ZD»Uýz-Ox6¸ J²oT¿¼èw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»¾É' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU@0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 ¸ÞéSd!¼äL+þ@¬Ø 9j¡2!,«YþÓb}U8°7sÜôfcb½áSpRç¨ØRé[-ªáÞϬ1TÔÈØ#¨ï+2},È|¨.wòDÑe MtµîÓst.;5rç@1ӲīçV¾ãû00 aI±thÆãøSȬ1ÌÀ .0 *H÷ 0Ì10UVeriSign, 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÷ 0«¼åO!² cuû!ç_ãÚFÓWðçínøíy>ϼ³$"ÎñÜeq¶Úß©Çï«túK?@K¬þ[REæâËH¶#»ÇS1w\¯lúè¾a7¦)ì_eÎËê66$±s²ùxT¿4×í˪/磵0²0 U00DU=0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø '¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿¤«É¨O³Eq!ÛÃnw) ´æ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4½ä×ŲAÿÅ,^56¥¢Ó°®oI÷ñ¿AÿæÅ1>0:0á0Ì10UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSȬ1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 060906182559Z0# *H÷ 1j._±¿ÛáâVº«0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSȬ1ÌÀ .0ô*H÷ 1ä á0Ì10UVeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSȬ1ÌÀ .0 *H÷ úëÜãû´6óÝK?ܦW¼]ÀêÐã¶1VzìWú`=®îBÎä¬RÉ/ >H+AN½Ü¸üßÏ©sÕ©JHs«Â´¾k\=` 1Ô Uoéûãókñ?v¦p¬Dí©|)ú´!É1#ÙñÂ1ê5þ -- 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
participants (1)
-
Ian Foster