January 2005 - ogsa-wg - lists.ogf.org

SetResourceProperty and WSDM
by Fred Maciel 28 Jan '05

28 Jan '05

Hi, > Should make WSDM aware about the 'set resource property' issue. > (Provided wants WSDM to be 'aligned' with the OGSA profile.) > Fred is the OGSA-WSDM liaison. I raised the issue at the WSDM teleconference earlier today. First of all, from the MUWS part 2 spec: "Specifically, the interface MUST include the GetResourceProperty operation defined by [WS-RP] and MAY include the GetMultipleProperties, SetResourceProperties and QueryResourceProperties operations." So, SetResourceProperties is not mandatory in WSDM. In the configuration capability, it says that: "WS- ResourceProperties SetResourceProperty operation MAY be used to change a configuration value." Again, not mandatory. So, whether SetResourceProperties is a MUST or not will depend on the specific mapping from MUWS to a given domain. And in the teleconference I was given a very good example, which is CIM. It is quite natural to do setup on resources (configure, control, etc.) using SetResourceProperties (that would be functionality similar to SetProperty, ModifyInstance, etc. in WBEM). This single operaton should be enough. Conversely, if we don't use it, we will need a *zillion* different operations (one for each and every property in every class of the model?), which will be a pain. So, no problems for now, but we (OGSA and WSDM) will definitely need to keep in sync. And I'd say that their input above is valuable. Regards, Fred Maciel. P.S. - For the WBEM operations, see: http://www.wbemsolutions.com/tutorials/CIM/wbem-operations.html

1 0

WSDM-related materials
by Fred Maciel 27 Jan '05

27 Jan '05

Hi, - Here is the URLs for the WSDM demo on the blackberry. http://www.oasis-open.org/committees/download.php/11086/WSDMDemo.010805.ppt - The presentation on the WSDM mapping to CIM, which was created by IBM, HP, CA and Cisco, is on the WSDM mailing list, but only available to TC members. Sigh... (They will publish the document -- they are working on the IP issues now). See ya, Fred Maciel.

1 0

EMS Teleconference minutes - 17 January 2005
by Andreas Savva 26 Jan '05

26 Jan '05

EMS teleconference minutes from Jan 17. Url: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-ems-20050117/… (Sorry for the delay. I wasn't actually asked to take minutes but Hiro wouldn't let me off the hook.) -- Andreas Savva OGSA EMS Teleconference - 17 January 2005 ========================================= * Participants Ravi Subramaniam (Intel) Dave Snelling (Fujitsu) Andreas Savva (Fujitsu) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Ian Foster (ANL) Dave Berry (UK NeSC) * General discussion - Agreed that the EMS space lacks concrete specs. - Initial focus on capabilities to guide effort in exploring the area---it seems premature to do an EM profile. - JSDL and WS-Agreement do seem to have some momentum behind them. But these pieces do not offer sufficient coverage to do a profile. - (Clarification that a Profile's purpose is interoperability.) - Proposal for discussing what a reasonable aim is---a gap analysis of sorts. - Agreed to the following: 1. Document the process of defining what we want to do a) Look at what there is in EMS (OGSA version 1.0) b) Subset it c) Union with outside specs d) Decide where new groups are needed (to fill the gaps) - Goal: short-term (candidate) profile that can produce something demonstrable - Clarification that "short term" means "year's end" - *Candidate* profile since it only has to identify the activity leading to a spec. - Detail concepts first? Might not finish until the profile is done. - Profile to cover as a minimum a "Hello world" level of functionality. 2. Look at what is there already in the EMS draft and what is the minimum subset that can be done as a first step. (To do.) 3. What is basic functionality? - Talk to a service/container/resource to start up something - If the executable is there just pass a path to it, or get it to the machine first---in some simple manner (no full-blown deployment configuration; just a data transfer) - (Ian) GT4 as an example that covers such simple functionality - (Dave) Unicore/unigrids as another example - Other efforts might offer input here, e.g., EGEE, etc - These examples might look very similar but their are subtle differences Proposal: Do a BoF on basic EM functionality. - The two projects above are willing to put forward complete WSDL specifications of relevant port types. This is important because they can be used as the starting point for standardization. - Should the entry point be the existence of WSDL specs? - Various opinions, but the rough consensus towards 'yes.' - Would like to also get Condor on-board (but need WSDL) - Condor has a WSDL sub-project: "Condor meets Soap" aka 'birdbath' - (DRMAA as an example that has an abstract definition but looks like a lot of work to put in WSDL) - Shared understanding that we can look at existing effors, invite groups to join, but cannot force participation in such a standards effort. And cannot just stop and wait. - Is there a preference to start from scratch? - Or, make sure that other efforts are also reviewed? - Consensus that it is easier to start from existing examples Action: Ian will send a pointer to the list describing the GRAM interfaces (Done) - Agreed that background work to review the various material is needed first. - For BoF need to also leave door open for people who may be proposing solutions not based on WSRF (e.g., OMII, etc) - The BoF is in addition to the profile work; fill the perceived gap in the EM space while the profile defines interoperability. - Clarified that the BoF is specifically on the submission interface; not the whole EMS space. - JSDL and WS-Agreement might be pieces used in the Profile. - (And might need more bofs for other pieces as gaps become more visible) - Forming such a group motivated/became obvious due to the work in EMS - Need/desire to make sure that it fits in OGSA-EMS - And that can only be done through participating in the proposed new group. Action: Work on drafting the charter for the BoF - Obviously do not to call it EMS; it is focused on a small subset: 'submission API' - This is not technical (design) work. - If the process is - (simple definition/provisioning), instantiation, execution, management - then BoF preparation is to decide what the minimal subset is. - Andrew and Dave volunteered to do a draft (initial proposal) of what is the important basic functionality and scope it as part of F preparation (initial proposal) (partly done) Additional actions: Action: Dave B to send WS-Agreement and DAIS link to the list. Action: Ravi volunteered to do a map of existing specs; what is there, now * Next EMS call: Jan 26 (to include BoF discussion) * OGSA EMS version 1.0 revision update - Andreas did a revision of the EMS section in OGSA version 1.0, to address some lingering issues: removing the term 'task' and modifying the explanation for 'Job' - Key changes: - Replace 'task' with generic 'unit of work' or delete as appropriate - Change order in definition of 'Job' so that the statement 'Job is a resource' comes later. Also remove too concrete statements (job is not workflow) that raised many comments at GGF12. Action: Andreas will fold in changes to next (final) draft and review in a subsequent call. (Done)

1 0

CMM document -- final call
by Fred Maciel 26 Jan '05

26 Jan '05

To: CMM-WG and OGSA-WG Hi, Here is version 28 of the CMM document, and a spreadsheet with the changes. (The main changes from last version were defining acronyms and correcting the references). Hopefully I will submit this one to the GGF editor. If you find any problems, please send to the CMM-WG and/or OGSA-WG mailing lists within one week. Thanks in advance, Fred Maciel.

1 0

Proposed agenda for Jan. 26th call
by Hiro Kishimoto 25 Jan '05

25 Jan '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on January 26th Wednesday from 5pm to 7pm (CST). 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: 0126 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 * Nov 23rd and Jan 24th calls: (maybe Jan 17th too) http://tinyurl.com/5fxfd/minutes-ems-20041123/ https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050124/en/1 Agenda bashing 2) Feb F2F meeting and GGF13 update (10 min) Andrew will submit F2F logistics if available. 3) Basic profile discussion (40 min) Tom will provide next version of BP before the call. 4) Basic EM profile discussion (30 min) - Catalog applicable standards - Review known standards wrt to the architecture - Identify initial set 5) Simple job API WG BoF discussion (30 min) Scoping for Job Creation and Management. Plan for GGF13 BoF. 6) Wrap up (10 min) AOB Jan. 31 (5pm-7pm CDT) OGSA roadmap discussion Feb. 2 (10am-noon CDT) Data design team Feb. 2 (5pm-7pm CDT) <TBD> ---- Hiro Kishimoto

1 0

Teleconference minutes - Jan. 24, 2005
by Andreas Savva 25 Jan '05

25 Jan '05

Minutes attached. Gridforge link: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050124/en/1 -- Andreas Savva Fujitsu Laboratories Ltd.

1 0

Re: [ogsa-wg] OGSA-EMS Meeting Agenda (2005-01-17)
by Ian Foster 24 Jan '05

24 Jan '05

Ravi: You've asked to pointers to relevant standards, but to first order there aren't any. That does make me wonder whether it is even possible to have a meaningful conversation about an EMS interoperability profile at this time, given that a profile is supposed to document an established use of established standards. I believe that the interfaces developed by the Globus team for GT4 GRAM are relevant to an EMS discussion, in that they represent the result of an intensive effort to develop WSRF-based job management interfaces. Documentation is at: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/ The concepts are described here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/key/WS_… And some of the interfaces here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/… Regards, Ian. At 11:14 PM 1/14/2005 -0800, Subramaniam, Ravi wrote: >Hi, > > > >Here is the agenda for this Mondays teleconference. As agreed at the last >F2F we will be focusing on developing an EMS interoperability profile. We >will use the Draft Profile template (Tom, Dave) as a reference (attached >for you convenience). We encourage persons who are active in relevant GGF >and other standard organization WG and people who are very familiar with >relevant standards to attend these meetings to provide the right and >informed perspectives and inputs. > > > >If you would be willing to educate the rest of the participants on one or >more applicable standards that you are very familiar with please let me >know and I can schedule some time. These would be brief overviews that >would lead to more detailed discussions in future as we narrow on the >appropriate set. > >Please send me pointers to definitive documentation on any standards that >you feel should be part of the EMS profile. I will compile these as >references for those who need to delve deeper. > > > >Dial-In > > > >Date: January 17th, 2005 (Monday) > >Time: 5 7 PM (CST) > > > >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/>http://ogsa.glance.net > > Session key: 0117 > > > >See more explanation: > ><http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html>http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html > > > >Agenda: > > > * Roll Call (5 mins) > * Agenda Bashing (10 mins) > * Ratification of previous minutes (5 mins) > * EMS profile discussion (tentative) (90 mins) > * Catalog applicable standards > * Review known standards wrt to the architecture > * Identify initial set > * Opens and wrap up. (10 mins) > > > > > >Thanks! > > > >Ravi _______________________________________________________________ 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

6 6

Data: Proposed agenda for Wednesday 26th January (also potential change of time)
by Dave Berry 24 Jan '05

24 Jan '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday January 26th, which will be at the usual time of 8.00am (PST) / 11.00am EST / 4.00pm (GMT) / 5.00 pm (CET). We have been asked to consider a slightly earlier time slot. Can people make half-an-hour earlier? UK Dial In: 0845 245 0224 USA Freephone: 1866 838 0046 International Dial In: +44 1452 542309 PIN: 632 065 (Reference 2527179) 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) - https://forge.gridforum.org/projects/ogsa-wg/document/Minutes_19th_Janua ry_2005/en/1 Agenda bashing 2) Update on outstanding actions (10 min) - Simon to mail the list about different types of metadata (data resource vs. service). - Dave to check with Dave Snelling when Basic Profile is ready for review. - Discuss time slot in e-mail. 3) Architecture issues (40 min) - I have been working on the straw man document, with input from a small group of people. This is beginning to take a coherent shape and I hope to distribute it more widely after next week's London meeting. The telcons are useful in resolving issues that arise while writing this straw man. - Is data transfer a service? - Are we transferring data (bits) or information (with some semantic content)? - Can we use the BasicFiles interface for both data and information? - How do we specify data types? - Other issues - Do we have volunteers to write subsections of the document? 5) Wrap up (5 min) AOB DONM - F2F in London, Feb 2nd. Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] FW: Issue #1 proposed resolution
by Ian Foster 24 Jan '05

24 Jan '05

I think the technical term is "carefully architected set of specifications" not "house of cards" (-: Regards -- Ian. At 05:10 PM 1/21/2005 +0000, Djaoui, A (Abdeslem) wrote: >Well, it probably doesn't, because WSRF is now decoupled from WS-Addressing >through the definition of the "abstract" resource Access Pattern, which >defines different embodiments for different ways of accessing state. > > >Abdeslem >/////////////// > >-----Original Message----- >From: Stephen Pickles [mailto:stephen.pickles@manchester.ac.uk] >Sent: 21 January 2005 17:05 >To: 'Djaoui, A (Abdeslem)'; 'OGSA-WG' >Subject: RE: [ogsa-wg] FW: Issue #1 proposed resolution > >Doesn't this make the whole house of cards (WSRF and OGSA) >come tumbling down? > >Please tell me I'm wrong! > >Stephen > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > > Behalf Of Djaoui, A (Abdeslem) > > Sent: 21 January 2005 09:47 > > To: 'OGSA-WG' > > Subject: [ogsa-wg] FW: Issue #1 proposed resolution > > > > > > Just in case you have not seen this, It appears RefProps will > > be removed > > from EPR's. Something we should discuss. > > > > Abdeslem > > ///////////////// > > > > -----Original Message----- > > From: public-ws-addressing-request(a)w3.org > > [mailto:public-ws-addressing-request@w3.org]On Behalf Of Ugo Corda > > Sent: 20 January 2005 01:33 > > To: Mark Little; Mark Baker > > Cc: public-ws-addressing(a)w3.org > > Subject: RE: Issue #1 proposed resolution > > > > > > > > Mark and Mark, > > It looks like RefProps are gone as of yesterday: see > > http://www.w3.org/2002/ws/addr/wd-issues/#i001 . > > > > Ugo > > > > > -----Original Message----- > > > From: public-ws-addressing-request(a)w3.org > > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > > Mark Little > > > Sent: Wednesday, January 19, 2005 5:26 PM > > > To: Mark Baker > > > Cc: public-ws-addressing(a)w3.org > > > Subject: Re: Issue #1 proposed resolution > > > > > > > > > > > > Mark, I have a distinct dislike for RefProps/RefParams, as > > > you're aware. However, putting my pragmatic hat on for a > > > moment, I don't see them vanishing in this release of the > > > specification. That doesn't prevent us from debating their > > > utility (or lack thereof), but I suspect it would be better > > > to take it off this mailing list if we're to try to maintain > > > the timeline that was proposed by the submitters and agreed > > > upon by the members of the group. Who knows, there may be a > > > change in a subsequent release? > > > > > > Also, I'm not sure why you moved my text around, but it could > > > change the context of what was originally intended. I didn't > > > mention the word "identification" at all in the proposed > > text I said. > > > > > > Mark. > > > > > > ---- > > > Mark Little, > > > Chief Architect, > > > Arjuna Technologies Ltd. > > > > > > www.arjuna.com > > > > > > > > > ----- Original Message ----- > > > From: "Mark Baker" <distobj(a)acm.org> > > > To: "Mark Little" <mark.little(a)arjuna.com> > > > Cc: <public-ws-addressing(a)w3.org> > > > Sent: Thursday, January 20, 2005 12:26 AM > > > Subject: Re: Issue #1 proposed resolution > > > > > > > > > > Mark, > > > > > > > > On Wed, Jan 19, 2005 at 10:41:53PM -0000, Mark Little wrote: > > > > > I think the pragmatic view on RefProps/RefParams has to > > > be that they > > > will > > > > > stay (rightly or wrongly, there are implementations and > > > > > specifications > > > out > > > > > there that now rely on them). > > > > > > > > This is a new spec we're working on, no? Those > > implementations can > > > > continue to depend upon whatever version of the spec they > > currently > > > > depend upon. Nothing we do here can break them, AFAICT. > > > > > > > > > I agree that the term "identifier" can be > > > > > contentious. However, so can the term "state". How about just > > > > > calling it/them "additional information that referencing > > > > > specifications [aka > > > using > > > > > specifications] or implementations need in order to ultimately > > > > > address > > > the > > > > > endpoint service"? > > > > > > > > >From my POV, there appears to be agreement to removing > > the part of > > > > >the > > > > spec that talks about using RefProps for identification. > > > Adding "in > > > > order to ultimately address" back in would be akin to > > undoing that > > > > change. The point of the change, as I see it, is to get > > > identifying > > > > information out of the RefPs, and into the URI, and I > > > consider that an > > > > enormous improvement over the WS-A submission. > > > > > > > > > That way we're not saying *what* goes in there, only > > > > > *why*. > > > > > > > > IMO, identification is a "what". > > > > > > > > Mark. > > > > -- > > > > Mark Baker. Ottawa, Ontario, CANADA. > > > http://www.markbaker.ca > > > > > > > > > > > > > > > > > _______________________________________________________________ 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

6 6

Teleconference minutes - 19 January 2005
by Andreas Savva 24 Jan '05

24 Jan '05

Minutes attached. Gridforge location: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050119/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 19 January 2005 ===================================== * Participants Abdeslem Djaoui (RL) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Steve Newhouse (OMII) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Latha Srinivasan (HP) Ravi Subramaniam (Intel) Jem Treadwell (HP) Minutes: Andreas Savva * Jan 10 and 12 minutes approved with no changes * F2F logistics - Place is Westin at O'Hare airport. - Logistics are not completely worked through yet. Action: Andrew to - Book conference room for the OGSA-WG meeting (3 days: Feb 14-16) - [And an additional one day for the non-OGSA meeting] - And let the group know of the room rate (for staying at the hotel) Action: Hiro will update F2F agenda, etc to reflect discussions and re-post. * GGF13 preparation - Hiro added InfoD to the RM session (now a shared session) and submitted the OGSA scheduling requests to Stacey. - There is a plan to do an EM-related BoF. Stacey should know about it but it is not the job of the OGSA-WG to tell her---the proposed-chairs should do it. Preparation has not progressed to that point yet so Andrew as Area Director will take care of it. Action: Andrew as Area director to send an email to the directors of the relevant Area (SRM: Bill, Stephen) to let them know of the proposed BoF; also to Stacey to reserve a slot. - Andrew mentioned that on the Data call there was a discussion for a similar BoF for Data. * Basic profile review Reference: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… ** Introduction/Front matter - Many changes since the last review. Because the document was still taking form these were not change tracked. The authors will do change tracking for future versions. - Ian re-wrote the Introduction. - Security section by Dave S. - Basic security addition is not reflected in the front matter yet. - Tom fleshed out many compliance statements. - Agreed to track issues via trackers. All comments should be deleted for the next version: either address in the text or move to the tracker, if substantial enough. Action: Andreas to create issues tracker. [Done. https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…] - Submit issues to the tracker directly or to the ogsa-wg list (and someone (probably Andreas) will put in the tracker.) The tracker is set to send mail to the list on addition of new artifacts only. ** Profile Conformance - Conformance targets need update. Probably some of these will be deleted. - Conformance Claim URI: Not defined yet. Reuse the WS-I approach. - There are two different types of statements marked with different prefix letters: {R, E} - [R]: Requirements statement. These are fairly consise. They may restrict but not extend an existing specification. (They should not be used to try and write new specifications.) - [E]: Extensibility points. Call out points where extensions may be made. E.g., where open content might be required. These highlight areas where behaviour may vary. (In a sense these are "warning flags.") ** Addressing - Using submission drafts as base; not trying to actively follow the latest ones. - R1002: Highlights an issue with the current spec.; the use of policy elements. Needs follow up. - R1003: It might be the case that the URL contains the ServiceName but this is not required. This statement is trying to codify the desired behaviour. *** 3.1.5 Resilient References - The intention is to describe ogsi-similar renewable references. - Focus is on capturing the renewable reference aspect and NOT on how to register a name so that it can be resolved. - 'Speculative' addition of rns:resolve since the RNS spec. may provide this operation. - There was a proposal for standardization of renewable references (RR). But it seems to be falling between the cracks of various groups: W3C Addressing group has placed it out of scope; WSRF does not seem to be the right place for it. *** 3.1.6 Reference properties - R1005: This statement will probably disappear into a tracker artifact. It is not easy to test or check. - In terms of terminology note that the profile deals with a particular message exchange. So terms like SENDER and CONSUMER are used instead of CLIENT/SERVER since the latter would describe a relation beyond a specific message exchange. - "Encoding scheme" might be work for a higher level profile. ("Correlateable properties?") *** 3.2 Addressing MIH Includes just boilerplate text for now. Need to think about it and revisit as WS-Addressing progresses. (It is expected that by March the W3C Addressing WG wil have a committee draft for this.) ** Resource embodiment - One major issue here is how far Data requirements can be accomodated while promoting interoperability. It might be good idea to schedule a joint-session with DAIS on this topic at GGF13. *** Resource properties **** 5.1.1 Property names - Qnames to point to the type of a resource property. And assume that the entity retrieving that information knows or can find out what they mean. - (There was a side-argument on why type information cannot be returned in general. Many implications if dynamic resource property elements are allowed and how they should be supported. Might want to record this as an issue but it is not likely to be something that can be solved in this profile.) - (DTDs were also mentioned as an alternative.) **** 5.1.2 Metadata descriptor WSRF has made this optional so it should not be made mandatory here. But it is probably a good idea to make it a separate section to draw out the relevant issues. *** 5.3 Query resource properties - (Issue) Requires XPath 1.0; but there is no standard serialization for an XPath response; so it ends up being implementation dependent. (XPath 2.0 on the other hand defines the response as well.) *** 5.4 ResourceProperty change notification - Might not want to require Topics. (Make no statements about their usage.) - Then they could not be used in a manner compliant to this profile but people could still experiment with them. And the profile could be kept simple for now. - Adding them in a later version would not affect other parts. *** 5.5 Set resource property - Another problematic function. Ordering issues are one typical issue (but there are other related issues discussed in the WSRF TC). - Revisit after checking with likely users: WSDM and possibly GT - Proposal at the moment is to give them the same treatement as Topics: say nothing about them and leave the field open for experimentation. ** 6 Resource lifetime - Not sure how far to mandate support for immediate destruction. - Proposal: A resource that can be created by message exchange should support immediate destruction - Might want to require response by all (even if a resource was statically created). - The semantics are defined by WSRF; not in the profile. In particular there was some discussion on what a destruction message means (in particular a successful reply). - A long discussion on whether to allow other behaviours, e.g., not mandate that a resource has to support this behaviour. It seemed to be due to a misunderstanding and it was agreed that the discussion should be taken offline; revisit in a later call if still an issue. *** 6.4 Notification of pending destruction - Might be something to propose to the WSRF group since it requires functionality not currently specified. ** Security - A first attempt to do a security profile segment. It uses the WS-I basic security profile, HTTP over TLS, and TLS - Note terminology: SENDER/RECEIVER not CLIENT/SERVER since the statements are with respect to message exchange roles as noted earlier. - It is transport-based security: not necessarily session-based--- it could be message-based. This seemed not to come out clearly enough from the text. - Contrast with WS-I basic security profile - WS-I profile statements are that "if something needs to be secured this is how it should be done" while this profile makes statemens on what functionality is required - Restricted authentication to just x509 certs. (And therefore disallowing username/passwd authentication.) This should probably be stated more clearly. ** Other business - Tom has the pen and will produce the next version of the basic profile document.

1 0