- ogsa-wg - lists.ogf.org

OGSA Basic Profile Telecon Agenda 4/6
by Tom Maguire 13 Apr '05

13 Apr '05

The following is a proposed agenda for OGSA-WG telecon on April 6th Wednesday from noon to 2pm (CDT) 1PM-3PM (EDT). The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0406 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Agenda bashing 2) Approve minutes from 3/30 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050330-OGSA… See AI below for update of minutes 3) Review AIs Action 1321: Frank & Sam to come up with text and schema for 1321 Action 1320: DaveS update text (text not captured need update of minutes) Action: 1298 should be closed no action (see minutes) Action 1231-1233: TomM to pull back 1231-33 into the document with empty body resolve message. Action 1317: TomM to make this a SHOULD with follow-on MUSTs (if implemented) Action 1262: TomM to remove from profile doc. 4) Security discussion (60 min) 1322: Use of Proxy Certificates 1323: Communication of assertions 5) Basic Profile discussion (50 min) 1211: What must a service satisfy before it can be called an "OGSA service?" 1314: Relationship to WS-I Basic Security Profile 1.0 6) Wrap up (10 min) AOB See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

4 6

Proposed agenda for April 13th call
by Hiro Kishimoto 13 Apr '05

13 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 13th Wednesday from 5pm to 7pm (CDT). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0413 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval May F2F meeting update (if any) Agenda bashing 2) OGSA roadmap document review (60 min) New draft will be available before the call. 3) Wrap up (10 min) AOB April 18 (5-7pm CDT) Profile template discussion April 20 (noon-2pm CDT) Basic Profile April 20 (5-7pm CDT) Roadmap discussion April 25 (5-7pm CDT) <TBD> April 27 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 1

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Savas Parastatidis 12 Apr '05

12 Apr '05

Dear Ian, I don't think that the approach I proposed forces the user to do more than they would have to do anyway if EPRs were used. It is still the case that someone has to manage the EPRs to the resources in WSRF. This is similar to what happens in the real world. The online bookstore will ask for my credit card number (a URI), or the book store will as for an ISBN (another URI) or multiple ISBNs if I want to buy multiple books. The banking service will ask for my bank account number (another URI perhaps). Also, there is no reason why a "kill all my jobs" message couldn't also be supported. But please note that this message is now addressed to the service (the container of resources) and not, as in the case of WSRF, to a specific resource. This is no different from what I am advocating. Also... to Steve's point about partial failure. If one wishes atomic transaction semantics, I don't see the difference from the two approaches... Atomic Msg -> resource 1 Msg -> resource 2 Msg -> resource 3 End Atomic Vs Msg Atomic Resource 1 Resource 2 Resource 3 End Atomic In fact, I would argue that the latter is better because: 1. It uses fewer messages (and, Steve, I am not assuming only HTTP and the optimisations that may be supported) 2. I can more easily deal with the failures in an application specific-manner since my atomic TX semantics do not span multiple msgs. (Anyway... who wants to do atomic TXs over the Web anyway? :-) Regards, -- Savas Parastatidis http://savas.parastatidis.name ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Tuesday, April 05, 2005 2:22 PM To: Steve Loughran; Savas Parastatidis Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions Steve's note raises a key point for me: do we really want to force the user (as Savas seems to be advocating) to keep track of jobs running at a remote site? I'd rather send a request "kill all my jobs" or "kill all my jobs that have run for more than a day" to the factory than carefully keep track of all jobs that I have active, and how long they have been running, so that I can send the big document (or stream) discussed below. Ian. At 02:10 PM 4/5/2005 +0100, Steve Loughran wrote: Savas Parastatidis wrote: Dear all, I think something needs to be clarified with regards to handling multiple jobs with one message. The beauty of document-oriented interactions is that you can do things like... <job-details-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> </job-details-request> Or <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> </job-suspend-request> The schema for the above document can allow anything from 0 to N number of <job-id> elements. the trouble with any bulk operation is you have to handle partial failure. You need either atomic operations (not long lived transactions over HTTP Savas, I wouldn't be that daft), or a way of indicating that only a bit went wrong Hence the 207 Multi-Status response in WebDav, the "something failed, look in the message". WebDav is still single instance (here a RESTy URL), but you can set >1 property and so have partial failure. SOAP just has SOAPFault and extensions; no explicit multiple failure response. WS-RF-ResourceProperties has a similar problem with SetResourceProperties, but a different failure model in which any failure to set can result in a WS-BaseFault, indicating which failed, but providing no apparent information on which worked. It seems to me that if you want to bulk stuff, you do need ways of (a) handling partial failure and (b) declaring what happens on partial failure. For the curions, WebDav's failure mode on file operations (MOVE, COPY) is explicitly declared to be that of failed file operations of Win98 on a FAT32 filesystem [1,2] Alternatively, you dont go for bulk operations, neither on a multiple jobs, or on multiple properties of a job (remember, WS-RF doesn't declare atomic/transacted property operations, so all you do here is increase the window of instability, a window that already exists). Instead you just stream a series of operations over the same HTTP1.1 connection -assuming that everything is accessible at the same far-end host, and get a series of (potentially out of order, we are talking HTTP1.1) responses. This could be efficient, and you could do better handling of failure. But you do need a SOAP stack that can keep an HTTP1.1 channel open for multiple requests. Axis doesnt, even if you get httpclient to do the HTTP work; I don't know about .NET/WSE. You also need developers to model the communication correctly. Manipulating JAXRPC proxies as if they represent remote objects is *clearly* the wrong way to do it. You'd almost want to model a queue of requests waiting to be POSTed, a queue you can fill up then push out. Something like this, in your Java-era language of choice :- //different queues for SOAP, REST Queue q=new Soap12RequestQueue(); q.add(new StatePut(job1.uri,Job.LIFECYCLE,Job.SUSPENDED)); //let the queue reorder stuff if it wants to q.add(new StatePut(job2.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_OPTIMAL); q.add(new StatePut(job3.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_LAST); q.setEventHandler(this); q.nonBlockingSubmit(); No, there is no code behind this example, and I am avoiding any hints as to what the even handler would look like. I think the key point is that once you embrace remote operations as async actions, then you can model the manipulations differently. Note also that I am representing job suspension not as an explicit suspend() operation, but as a request to put a job into the suspended state. This API could work with our friend REST just as easily as with WS-RF... Anyway Savas, to conclude: do you have any evidence that a single document is suboptimal compared to a sequences of requests over an open HTTP/1.1 connection? That is, assuming we ignore the SHOULD in the HTTP1.1 specification " Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods" [3] -Steve [1] WebDav http://www.ietf.org/rfc/rfc2518.txt S8.9.2 "after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible." [2] http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html [3] RFC2616 HTTP1.1 _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

3 2

Proposed agenda for April 11th call
by Hiro Kishimoto 11 Apr '05

11 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 11th Monday from 5pm to 7pm (CDT). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0411 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval - http://tinyurl.com/5fxfd/minutes-20050406/en/1 May F2F meeting update (if any) Agenda bashing 2) profile policy statement discussion (30 min) This is time boxed discussion. Since the OGSA is GGF's flagship architecture, the GFSG has been working on a policy surrounding the creation of profiles for OGSA. David Snelling, our Area Director, has done a FIRST DRAFT ("The OGSA Evolution Policy Statement"). Please read this draft and give your feedback. David and I will bring your feedback to GFSG to improve the policy statement. https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-evolution-policy… ement/en/1 3) Fellow WGs status report (60 min) - OGSA-ByteIO WG - OGSA-Data WG - OGSA-BES WG - OGSA-naming WG 4) Wrap up (10 min) AOB April 13 (noon-2pm CDT) Basic Profile April 13 (5-7pm CDT) Roadmap discussion April 18 (5-7pm CDT) Profile template discussion April 20 (noon-2pm CDT) Basic Profile April 20 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

2 1

Virtualization: How do we specify notifications?
by Dave Berry 08 Apr '05

08 Apr '05

Dear OGSA WG, In the object-oriented world, components such as Java Beans or ActiveX controls are typically defined by a set of properties, a set of methods and a set of events. In the service-oriented world we have a similar requirement, dealing with interoperable messages rather than a language API. What is the best way to specify the notifications that a service or interface can send? The OGSA document describes a virtualization as a "common set of abstract interfaces available for a set of similar resources, thereby hiding differences in their properties and operations". To this we somehow have to add the notifications that can be generated, as these are an essential part of virtualization. Are the notifications part of an interface? Are they actually specified in any of the metadata for a service? The OGSA document defines an interface as follows: "In a service-oriented architecture, a specification of the operations that a service offers its clients". Should this be extended to include properties and/or notifications? This is a live issue for the Data Architecture document. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

2 1

OGSA Basic Profile minutes posted
by Treadwell, Jem 08 Apr '05

08 Apr '05

Hi, the minutes of this week's Basic Profile telecon are now posted at http://tinyurl.com/6c3rv. Please let me know if you see any errors or omissions - thanks! - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

Data: Proposed agenda for Wednesday 13th April
by Dave Berry 08 Apr '05

08 Apr '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday April 13th, which will be at the usual time of 7.30am PDT / 10.30am EDT / 3.30pm BST / 4.30pm CEST UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) - http://tinyurl.com/5y324 Agenda bashing 2) Action report (5 min) - Dave to send charter to GFSG [done]. - Dave to consult re F2F meeting [see next section]. - Dave to remind contributers of schedule [done]. 3) F2F planning (10 min) The main OGSA WG meeting will be May 23-24 with a data day planned on May 25. May 25 overlaps with an EGEE meeting - is there another day that suits everybody? 4) Replication (25 min) Update from Anne and Allen on the replication section and a discussion of remaining issues. 5) Architecture document structure (10 min) Comments on the structure of the architecture document. 6) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

OGSA ByteIO telcon, April 12th
by Dave Berry 08 Apr '05

08 Apr '05

Dear all, I've booked a telcon for the nascent ByteIO group. This will be next Tuesday at 8AM Pacific, 11AM Eastern, 4PM UK and midnight in Japan. We will start the technical discussion, focussing on the protocol for transferring the bytes. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Mark McKeown 07 Apr '05

07 Apr '05

Hi Paul, Moving the question from can I suspend multiple jobs by sending a single message to a resource (either REST or WS-Resource) to weither this is a good thing. There is a balance between simplicity and efficiency - using a single message intoduces more complexities, as Steve Loughran illustrated, but is potentially more efficient than sending mutliple messages. Remembering that "Early optimisation is the root of all evil" (Knuth) - is adding support for suspending mutiple jobs using a single message an example of early optimisation? I would imagine that this should be a straight forward question since there is already considerable experience in using computational grids. Are users demanding the ability to suspend mutliple jobs using a single message? Is it for improved efficiency reasons? From my experience no, but others on this list will have considerably more experience. Could this be a case of "worse is better", simplicity is more important than efficiency? Perhaps there are other reasons for using a single message to interact with multiple jobs? cheers Mark > Ian, > > > > I agree that this is good progress. So let's bank that and see if we can > we can agree on one more thing, and then I'll ask a question. > > > > Considering your list of abilities (a, b & c) below, do we agree that in > terms of expressiveness, the ordering is: > > > > c>b>a > > > > i.e. using approach c, a client can request operations on: > > a) single jobs: "where (jobid = urn:guid:364)" > > b) sets of jobs: "where (jobid = urn:guid:364) or (jobid = > urn:guid:401)" > > > > If there is agreement on this, then we could move on to discussing why > it is felt necessary to provide more than just c for the job submission > service. > > > > Regards > > Paul > > > > Ian wrote... > > >Savas: > > > > > >It seems that we are in agreement, then, that we want the ability to: > > > > > >a) Request operations on individual jobs identified by some sort of > "jobid" > > > > > >b) Request operations on sets of jobs identified by a user-supplied > list of "jobids" > > > > > >c) Request operations on sets of jobs identified by more abstract > criteria > > > > > >We also agree that (as I expressed in the email that started this > discussion) such >requests can be expressed in a few different ways, > with somewhat different >characteristics. > > > > > >That's progress I hope. > > > > > >Ian. > > > > ________________________________ > > From: Ian Foster [mailto:foster@mcs.anl.gov] > Sent: 05 April 2005 17:59 > To: Savas Parastatidis; Steve Loughran > Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; > dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; > grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; > mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry; Paul Watson > Subject: RE: [ogsa-wg] RE: Modeling State: Technical Questions > > > > [I'm feeling increasingly bad about sending email to all of the people > CCed here, who may not be interested in these issues at all but got > addressed by Tony long ago...] > > Savas: > > It seems that we are in agreement, then, that we want the ability to: > > a) Request operations on individual jobs identified by some sort of > "jobid" > > b) Request operations on sets of jobs identified by a user-supplied list > of "jobids" > > c) Request operations on sets of jobs identified by more abstract > criteria > > We also agree that (as I expressed in the email that started this > discussion) such requests can be expressed in a few different ways, with > somewhat different characteristics. > > That's progress I hope. > > Ian. > > At 02:44 PM 4/5/2005 +0100, Savas Parastatidis wrote: > > > > > Dear Ian, > > > > I dont think that the approach I proposed forces the user to do more > than they would have to do anyway if EPRs were used. It is still the > case that someone has to manage the EPRs to the resources in WSRF. This > is similar to what happens in the real world. The online bookstore will > ask for my credit card number (a URI), or the book store will as for an > ISBN (another URI) or multiple ISBNs if I want to buy multiple books. > The banking service will ask for my bank account number (another URI > perhaps). > > > > Also, there is no reason why a kill all my jobsmessage couldnt also be > supported. But please note that this message is now addressed to the > service (the container of resources) and not, as in the case of WSRF, to > a specific resource. This is no different from what I am advocating. > > > > Also& to Steves point about partial failure. If one wishes atomic > transaction semantics, I dont see the difference from the two > approaches& > > > > Atomic > > Msg -> resource 1 > > Msg -> resource 2 > > Msg -> resource 3 > > End Atomic > > > > Vs > > > > Msg > > Atomic > > Resource 1 > > Resource 2 > > Resource 3 > > End Atomic > > > > In fact, I would argue that the latter is better because: > > > > 1. It uses fewer messages (and, Steve, I am not assuming only HTTP and > the optimisations that may be supported) > > > > 2. I can more easily deal with the failures in an application > specific-manner since my atomic TX semantics do not span multiple msgs. > > > > (Anyway& who wants to do atomic TXs over the Web anyway? :-) > > > > Regards, > > -- > Savas Parastatidis > http://savas.parastatidis.name > > > > > From: Ian Foster [mailto:foster@mcs.anl.gov] > Sent: Tuesday, April 05, 2005 2:22 PM > To: Steve Loughran; Savas Parastatidis > Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; > dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; > grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; > mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry > Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions > > > > Steve's note raises a key point for me: do we really want to force the > user (as Savas seems to be advocating) to keep track of jobs running at > a remote site? > > I'd rather send a request "kill all my jobs" or "kill all my jobs that > have run for more than a day" to the factory than carefully keep track > of all jobs that I have active, and how long they have been running, so > that I can send the big document (or stream) discussed below. > > Ian. > > > At 02:10 PM 4/5/2005 +0100, Steve Loughran wrote: > > Savas Parastatidis wrote: > > Dear all, > I think something needs to be clarified with regards to handling > multiple jobs with one message. The beauty of document-oriented > interactions is that you can do things like... > <job-details-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> > </job-details-request> > Or > <job-suspend-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> > </job-suspend-request> > The schema for the above document can allow anything from 0 to N number > of <job-id> elements. > > > the trouble with any bulk operation is you have to handle partial > failure. You need either atomic operations (not long lived transactions > over HTTP Savas, I wouldn't be that daft), or a way of indicating that > only a bit went wrong > > Hence the 207 Multi-Status response in WebDav, the "something failed, > look in the message". WebDav is still single instance (here a RESTy > URL), but you can set >1 property and so have partial failure. > > SOAP just has SOAPFault and extensions; no explicit multiple failure > response. WS-RF-ResourceProperties has a similar problem with > SetResourceProperties, but a different failure model in which any > failure to set can result in a WS-BaseFault, indicating which failed, > but providing no apparent information on which worked. > > It seems to me that if you want to bulk stuff, you do need ways of (a) > handling partial failure and (b) declaring what happens on partial > failure. For the curions, WebDav's failure mode on file operations > (MOVE, COPY) is explicitly declared to be that of failed file operations > of Win98 on a FAT32 filesystem [1,2] > > Alternatively, you dont go for bulk operations, neither on a multiple > jobs, or on multiple properties of a job (remember, WS-RF doesn't > declare atomic/transacted property operations, so all you do here is > increase the window of instability, a window that already exists). > Instead you just stream a series of operations over the same HTTP1.1 > connection -assuming that everything is accessible at the same far-end > host, and get a series of (potentially out of order, we are talking > HTTP1.1) responses. > > This could be efficient, and you could do better handling of failure. > But you do need a SOAP stack that can keep an HTTP1.1 channel open for > multiple requests. Axis doesnt, even if you get httpclient to do the > HTTP work; I don't know about .NET/WSE. You also need developers to > model the communication correctly. Manipulating JAXRPC proxies as if > they represent remote objects is *clearly* the wrong way to do it. You'd > almost want to model a queue of requests waiting to be POSTed, a queue > you can fill up then push out. Something like this, in your Java-era > language of choice :- > > //different queues for SOAP, REST > Queue q=new Soap12RequestQueue(); > > q.add(new StatePut(job1.uri,Job.LIFECYCLE,Job.SUSPENDED)); > //let the queue reorder stuff if it wants to > q.add(new > StatePut(job2.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_OPTIMAL); > q.add(new > StatePut(job3.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_LAST); > > q.setEventHandler(this); > q.nonBlockingSubmit(); > > No, there is no code behind this example, and I am avoiding any hints as > to what the even handler would look like. I think the key point is that > once you embrace remote operations as async actions, then you can model > the manipulations differently. Note also that I am representing job > suspension not as an explicit suspend() operation, but as a request to > put a job into the suspended state. This API could work with our friend > REST just as easily as with WS-RF... > > Anyway Savas, to conclude: do you have any evidence that a single > document is suboptimal compared to a sequences of requests over an open > HTTP/1.1 connection? That is, assuming we ignore the SHOULD in the > HTTP1.1 specification " Clients SHOULD NOT pipeline requests using > non-idempotent methods or non-idempotent sequences of methods" [3] > > -Steve > > > [1] WebDav http://www.ietf.org/rfc/rfc2518.txt S8.9.2 > > "after encountering an error moving a non-collection > resource as part of an infinite depth move, the server SHOULD try to > finish as much of the original move operation as possible." > > [2] > http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html > > [3] RFC2616 HTTP1.1 > > _______________________________________________________________ > Ian Foster www.mcs.anl.gov/~foster > Math & Computer Science Div. Dept of Computer Science > Argonne National Laboratory The University of Chicago > Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. > Tel: 630 252 4619 Fax: 630 252 1997 > Globus Alliance, www.globus.org <http://www.globus.org/> > > _______________________________________________________________ > Ian Foster www.mcs.anl.gov/~foster > Math & Computer Science Div. Dept of Computer Science > Argonne National Laboratory The University of Chicago > Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. > Tel: 630 252 4619 Fax: 630 252 1997 > Globus Alliance, www.globus.org <http://www.globus.org/> > >

7 6

ByteIO charter: ready for GFSG?
by Dave Berry 07 Apr '05

07 Apr '05

Dear all, I'd like, if possible, to send the draft charter for the OGSA ByteIO group to the GFSG before their next meeting on Tuesday. See the attachment for a version that I've updated in the light of comments received. Please send any comments to the co-chairs and me by Sunday. If there are no unresolved issues I'll submit it to the GFSG on Monday, for discussion at their meeting on Tuesday. They will then make it open for comment for another 7 days. If there are unresolved issues, we can discuss them on next Tuesday's telcon (details to follow). Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0