GGF13 OGSA-WG session #6: Basic Profile (2 of 2) =============================================== Lead: Tom Maguire Notes: Jem Treadwell Hiro opened with GFSG's question about whether design teams would be interested in becoming new working groups (first raised at the prior Basic Profile discussion). After having thought about it overnight, Tom feels that the membership would be the same, so doesn't see much benefit. We should attempt to get a feel from the community for whether more people would help with the work if it was a WG; if so, we should move forward. Can the GFSG address that before GGF13 finishes? Hiro: this makes sense; will take Tom.s comment back to the GFSG. Tom shows agenda slide; continue from yesterday's session. Reviewed trackers opened following that session. Should there be a Separate security profile? Dave Snelling: Inclined to keep it in the Basic Profile, because it's fundamental to Grid. It isn't that big a section; guidance from GFSG might require us to open yet another WG. Tom: we need to make this an agenda item for a telecon meeting when Frank will be present. Savas: "Would you consider making a TCP/IP Basic Profile?" making the point that this is infrastructure, not necessarily appropriate for high-level Grid specification. Possible problems with tooling, libraries etc. Tom: Profiles don't really imply changes to tooling; it's a proper subset of a particular set of specs. Savas: if you want to be more restrictive then you have to go down to the tooling to make it conform to your restrictions, rather than to WS-I. Tom/Dave: Not really true, though some things could break some badly-written tooling. Tom: If we're a proper subset of WS-I or any other specification we're referencing then I don't see how we can get into trouble. Savas: willing to move on; only experience will tell, but there could be issues with tooling. Tracker 1317 (Dave): QueryRP should be optional: Related to 1254, resolved in Feb as mandatory. Concern: QueryRP is complex and fragile technology; can be broken by "smart" tooling doing optimizations. Dave would prefer a RECOMMENDED or SHOULD rather than a MUST. Tom: thinks that Sam Meder would agree, but may have changed his position. Currently Open; Tom will change to Pending. Tracker 1258: Should we require RP-ChangeNotification? (Open) Prefer not to have references to non-standardized specs. It's possible that BaseNotification may not be at Committee Draft by the time we're ready to publish (July/Aug latest). (discussion) Tom: Happy to say that if you want Notification here's the set of things you need to do; language in WSRP is pretty strong; maybe we just need to clarify. Dave: comfortable to say that if it supports NotificationProducer then MUST support ChangeNotification. But we would have to remove the requirement if BaseNotification is not standardized in time for us to go to Proposed Recommendation. Set tracker to Resolved. (Discussion about differences in standards process between GGF & OASIS). Dave: The WSRF Technical Committee (TC) might choose to go to Committee Draft, then maybe to Public Comment, but not go to Standard until the WS-A issue is resolved. Tom: There is a genuine desire to sync if it can be done in a reasonable timeframe. Savas: Question about when namespace can be determined. Tom: W3C is changing their rules. OASIS requires that the TC can't make change after Committee Draft without restarting the process. Tracker 1262: Should we require SetResourceProperties? (Discussion) Semantic complexity; non-deterministic etc. - may be difficult to build interoperable systems that use SetResourceProperties. Dave proposes restricting usage to UpdateResourceProperties, since that restricts you to existing properties, and is semantically clean. Proposed recommendation; move status to Pending. Dave: Need to consider the current thinking regarding Basic Profile surrounding 'core mandated requirements' vs 'conformance target requirements'. To be clearer should the Basic Profile mandate that use of say WS-ResourceProperties OR should the Basic Profile describe the requirements on WS-ResourceProperties IF the service uses WS-ResourceProperties. Currently a mix of both of these: IF you do this you MUST do that. Desire from GFSG for us to look at a second (non-WSRF) profile. Savas: consider taking WSRF out of Basic Profile and pushing it further up the stack, make Basic Profile a common denominator that everyone agrees on. WS-I took a long time, and did the minimum to enable everyone to agree. Basic Profile could take the same approach. Dave: "Nomenclature" proposal: this is not a Basic Profile, it's a "WSRF Profile of OGSA". So there's tension with the name. I would like the profile to say that anything with a MUST must be conformed to by anything implementing OGSA. That would be a core statement. Hiro: OGSA-WG is under pressure to bring out an implementable specification. WS-I did not have this pressure. Savas: agree, but that's why it.s up to WS-I to do the hard work, and OGSA to build on WS-I. We should build high-level services based on WS-I, don't require WSRF. Hiro: need interoperability and interchangeability; can't do that if everyone defines their own. Discussion about the semantics of Destroy operation as an example. Savas: Build services on widely-adopted standards (SOAP, WSDL & WS-Security). Tom: there are only a couple of hard-core requirements to comply with BasicProfile as it stands today: very little is required to comply with it! Savas: Common behavior goes away as services need to add/extend operations. Dave asked that Savas not have the last word, and Tom then closed the meeting, so he didn't.