Simon Holdsworth: Audio conference:
Meeting Number: * 913929 * (press * before and after the digits)
Phone numbers:
Austria = Vienna 026822056419
Belgium = Brussels 022901709
China Toll Free = China North 108007121722, China South 108001201722
Denmark = Copenhagen 32714982
France = Paris 0170994364, Lyon 0426840196, Marseilles 0488915310
Germany = Berlin 030726167296, Frankfurt 069710445413, Hamburg 040809020620, Munich 089244432767, Stuttgart 0711490813212, Dusseldorf 021154073845
India Toll Free = 0008001006703
Ireland = Dublin 014367612
Italy = Milan 0230413007, Rome 06452108288, Turin 01121792100
Japan = Tokyo 0357675037
Netherlands = Amsterdam 0207965349
Portugal = Lisbon 211200415
Russia Toll Free = 81080022074011
Spain = Barcelona: 934923140, Madrid: 917889793
Sweden = Stockholm 0850520404
Switzerland = Geneva 0225927186
UK Toll Free = 08003581667
UK Toll = London 02071542988, Manchester 01612500379, Birmingham 01212604587
USA Toll Free = 18665289390
USA Toll = 19543344789
Please change your name from 'anonymous' using the Settings button
Simon Holdsworth: 1. Opening
Introductions
Roll call
Scribe assignment
Top 10 on the scribe list (full list below, brackets indicate currently non-voting members):
(Michael Beisiegel IBM)
(Sanjay Patil SAP AG)
Nimish Hathalia TIBCO Software Inc.
Plamen Pavlov SAP AG
Vladimir Savchenko SAP AG
Eric Johnson TIBCO Software Inc.
Ashok Malhotra Oracle Corporation
David Booz IBM
Khanderao Kand Oracle Corporation
Laurent Domenech TIBCO Software Inc.
Agenda bashing
2. Approval of minutes of SCA-Binding TC meeting of 23rd October
http://www.oasis-open.org/committees/download.php/29795/SCA%20Bindings%20minutes%202008-10-23.doc
3. Actions
20080304-9 [Editors] Update specs as necessary for ASSEMBLY-55 close no action.
20080717-4 [Sanjay Patil] Provide examples for issue 24
20080717-6 [Vladimir Savchenko] Send out a proposal for how WSDL bindings and portTypes relate to each other. Target: 14th August
20080717-10 [Simon Holdsworth] Submit proposal for issue 7. Pending acceptance/resolution of Policy issue
20080904-1 [Editors] update SOAP intent as per email http://lists.oasis-open.org/archives/sca-bindings/200808/msg00072.html
20081009-1 [Simon Holdsworth] Produce specific resolution text for issue 42
20081016-1 [Editors] Update JCA bindings spec to clarify there are no may provides or always provides intents
20081023-1 [Anish Karmarkar] Produce updated proposal for BINDINGS-2 with additional fault details
20081023-2 [Mike Edwards] Raise issue in Assembly on need for callback WSDL annotation
4. New Issues
Please note, as per resolution on 9th October 2008, new issues received on the mailing list after Noon GMT 1st November can only be opened using the same voting rules as re-opening a closed issue (2/3 majority of a full TC vote)
No new issues
5. RFC2119 updates to specifications
Need to identify any significant issues, and whether editors can proceed to apply issue resolutions on top of RFC2119 rewording in the specs
o http://www.oasis-open.org/committees/download.php/29727/sca-binding-ws-1.1-spec-cd01-rev2.doc
o http://www.oasis-open.org/committees/download.php/29718/sca-binding-jca-1.1-spec-cd01-rev2.doc
o http://www.oasis-open.org/committees/download.php/29684/sca-binding-jms-1.1-spec-cd01-rev1.doc
6. Submission for HTTP binding
Discuss submission with respect to including this binding in the 1.1 release, and if so, outlook for first committee draft.
http://lists.oasis-open.org/archives/sca-bindings/200810/msg00078.html
7. Open Issue Discussion
Open issues with proposed resolutions:
http://www.osoa.org/jira/browse/BINDINGS-2
How should SCA callback semantics be carried over Web Services?
Raiser: Simon Nash, owner: Anish Karmarkar
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200808/msg00071.html Latest email: http://lists.oasis-open.org/archives/sca-bindings/200808/msg00073.html
http://www.osoa.org/jira/browse/BINDINGS-11
"Formal" WSDL generation is unclear, ambiguous, and incomplete
Raiser: Eric Johnson, owner: Eric Johnson, Anish Karmarkar
Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00012.html
http://www.osoa.org/jira/browse/BINDINGS-31
What is a "plain name" for a connection factories or activation specs, and how is one distinguished from a JNDI name?
Raiser: Eric Johnson, owner: Simon Holdsworth
Status: Updated proposal in email http://lists.oasis-open.org/archives/sca-bindings/200810/msg00013.html
http://www.osoa.org/jira/browse/BINDINGS-40
Clarify rules around combination of destination, CF and AS elements
Raiser: Simon Holdsworth, owner: Simon Holdsworth
Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00077.html
http://www.osoa.org/jira/browse/BINDINGS-44
Update binding.jms spec for wireFormat/operationSelection elements
Raiser: Simon Holdsworth, owner: Simon Holdsworth
Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00073.html
Open issues with identified resolution owner:
http://www.osoa.org/jira/browse/BINDINGS-7
JMS bindingType and ordered intent - clarification needed
Raiser: Peter Peshev, owner Simon Holdsworth
Status: Awaiting decision on POLICY-60.
http://www.osoa.org/jira/browse/BINDINGS-21
Support for callback and conversation ID-s in bindings
Raiser: Peter Peshev, owner Peter Peshev
Status: Proposed resolution in issue
Notes: As for BINDINGS-2, this is waiting for clarification around conversations at the assembly level
http://www.osoa.org/jira/browse/BINDINGS-43
Update binding.ws spec for wireFormat/operationSelection elements
Raiser: Simon Holdsworth, owner: Anish Karmarkar
Status: Specific resolution text required.
http://www.osoa.org/jira/browse/BINDINGS-45
Update binding.jca spec for wireFormat/operationSelection elements
Raiser: Simon Holdsworth, owner: Piotr Przybylski
Status: Specific resolution text required.
Open issues with no identified resolution owner:
http://www.osoa.org/jira/browse/BINDINGS-22
Bindings specifications should provide exemplary Implementations for Callbacks and Conversations
Raiser: Mike Edwards
Status: No proposed resolution
Notes: As for BINDINGS-2, this is waiting for clarification around conversations at the assembly level
http://www.osoa.org/jira/browse/BINDINGS-23
@wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs
Raiser: Eric Johnson
Status: Specific resolution text required
http://www.osoa.org/jira/browse/BINDINGS-24
Which wire did a message arrive on?
Raiser: Sanjay Patil
Status: Waiting for examples from Sanjay as per 20080717-4
http://www.osoa.org/jira/browse/BINDINGS-25
Is it required that every implementation of binding.ws support the soap intent?
Raiser: Anish Karmarkar
Status: No current proposal. Latest email: http://lists.oasis-open.org/archives/sca-bindings/200807/msg00006.html
http://www.osoa.org/jira/browse/BINDINGS-29
Properties on Bindings
Raiser: Piotr Przybylski
Status: No current proposal; defer until Policy 15 (External Attachment) is resolved
8. AOB
anonymous morphed into Eric Johnson
Eric Johnson: Scribe: eric
Eric Johnson: topic - approval of the minutes.
Eric Johnson: No objections to approving the minutes.
Eric Johnson: Minutes are approved.
Eric Johnson: Topic: action items.
Eric Johnson: Anish: 20081023-1 completed.
Eric Johnson: Mike Edwards: 20081023-2 - just completed.
Eric Johnson: Topic - new issues - none
Eric Johnson: Topic #5 RFC 2119 language revisions
Eric Johnson: Simon: Should we continue to update the documents with issue resolutions waiting to be applied?
Eric Johnson: Anish: (Reacting to comments on WS-binding) Agree with some of the comments so far, disagree with some.
It would be confusing to merge issue resolution with RFC2119 language. Either we should branch, and figure out how we're going to merge, or we should prioritize RFC 2119 language issues so that we can combine.
Eric Johnson: Simon: Concerned that there are not any comments on the other two documents at all.
Eric Johnson: ... (to Anish) are you prepared to discuss?
Eric Johnson: Anish: Go-round on the mailing list would be useful. Anish will respond to comments on mailing list.
Mike Edwards: +1 to getting the RFC 2119 stuff done asap
Eric Johnson: Simon: Everyone please review. Post your messages on the mailing list.
Eric Johnson: Eric: Seems like we need to file issues against the existing RFC 2119 language.
Eric Johnson: Simon: There is an implicit issue and implicit issue resolution. Comments on the RFC 2119 language is comment on that implied issues.
Eric Johnson: Dave Booz: Should we file the comments as issues?
Eric Johnson: Eric: Since concerns around RFC 2119 language imply confusion about the intent of the spec, those naturally map to issues.
Eric Johnson: Simon: We could propose to accept the text as it stands, and then raise issues against text.
Eric Johnson: Simon: Can I have a proposal to raise issues against the specs?
anish the deadline is for raising issues, not accepting it
Eric Johnson: ... we can come back to the RFC 2119 updates later in the call.
Eric Johnson: Topic: Accepting the submission for the HTTP binding.
Eric Johnson: ... possibility of an HTTP binding was left open by the charter. But we've not had a formal proposal. Simon felt we should get it on the table for the TC to look at and discuss.
Should we include it in the overall 1.1 release? Any comments on it?
Eric Johnson: Dave Booz: What is it we're trying to accomplish with that binding? Are we trying to facilitate a RESTful style interaction, or an RPC style interaction?
Bryan Aupperle: s/Dave Booz/Bryan Aupperle/
Eric Johnson: Simon: Nothing specific in this document about JSON, REST, etc. Use wire format and operation selection to provide additional capabilities. Rather, just designed to set up HTTP connectivity.
Dave Booz Eric, RFC2119 new issue email has left my machine
Eric Johnson: ... response element similar to JMS. SSL settings (although that perhaps should be stated as intents). Headers element - similar to JMS - set standard headers. Operation properties element to set properties for a specific operation. Then a description of all of those elements, and a default operation and data binding.
Eric Johnson: Bryan: What's the minimum that we have to specify?
Eric Johnson: Anish: Need to look at the document in detail. Hard to see how this binding would make the rest-heads happy. Operations are not really a part of "REST". GET, PUT, DELETE
Eric Johnson: ... is this possible with existing binding.ws?
Eric Johnson: Mike E.: You've already failed the test of the REST guys if you require WSDL.
Eric Johnson: Anish: If this is not meant for REST, and it is HTTP specific, what value do we add by providing a separate binding?
anish another thing we should look at is WADL
anish i think there are major religious/philosophical difference between the REST-heads and WS-heads and mixing the two will not make the REST-heads happy
Eric Johnson: Simon: If you look at the operation selector for REST, it is simple. Operation selector needs to do more work for "services"
Martin C (not on the call, just watching the room) morphed into Martin C
Dave Booz i thought they were called REST-afarians
anish 
indeed
Eric Johnson: Martin: REST people would say "why are you bothering?" It is a different architectural paradigm. REST is about stateless transfer. Why would be bother?
Eric Johnson: Simon: Two cases we might care about - developing from scratch - maybe not - but what about extending an existing service? If you do SCA - do we want to enable connections to REST items.
Eric Johnson: Bryan: RESTful functionality is all about hypermedia documents linking to other documents. Interfaces don't map to typical Java POJOs.
anish REST-ful idea is also about small number of verbs and infinite number of nouns. We don't do that when we allow interfaces
Eric Johnson: Simon: providing this for SCA services is a stretch, but providing it for references - that might work.
Eric Johnson: Eric: Probably need a different interface if you're going to support RESTful services
Eric Johnson: Martin: Call a spade a spade. Don't want to make the mistake of document management folks who claim to have restful interfaces.
Eric Johnson: Anish: If we're not making RESTifarians happy, then what is it we get with this binding that we don't get with binding.ws?
Eric Johnson: Simon: This provides customizability of the HTTP binding that we don't have with the binding.ws.
Eric Johnson: Eric: Different way of casting it - Simon has highlighted a limitation of the binding.ws spec.
Eric Johnson: Simon: We need to decide whether to pursue this further.
anish i don't think i'm ready to say one way or another
Eric Johnson: Mike E.: We need to make a motion to engage the HTTP work. (Making a motion...)
anish: i should note that WSDL 2.0 HTTP binding takes care of all the short comings of WSDL 1.1 HTTP binding
Mike Edwards: Mike E moves that the Bindings TC start work on a binding.http specification, starting with the creation of an initial working draft, using the contributed binding.http document as a starting point.
anish: it has support for serialization, query params, http headers, auth schemes etc
Eric Johnson: Motion from Mike E., 2nd Dave Booz.
Eric Johnson: Martin: We've not had time to discuss at Oracle - would like some time to think about it. Perhaps would like to table for a week?
Eric Johnson: Mike E.: I would support tabling for a week.
Dave Booz Anish, you mentioned auth schemes...not sure a wsdl spec is the right place for that
Eric Johnson: Motion tabled for a week. (Simon will add to next week's agenda)
Eric Johnson: (No objections to table the motion.)
Dave Booz one of my concerns on this binding is that there's some policy config which should be removed
Eric Johnson: Simon: Please indicate your possible attendance at the F2F in the open ballot.
Eric Johnson: Topic: Open issues
Eric Johnson: Subtopic: Issue-2
Eric Johnson: Anish: Have you seen the mailing list meta-discussion? Whether we should do this, and whether if we do this, does it violate the scope of the charter. Is this an example of how you may do this, or is this how you MUST do it, but it is optional? First, talk about scope.
Eric Johnson: Dave B.: Don't have an objection to documenting what we want to do. Objection is to normative. If it isn't normative, then scope doesn't apply.
Eric Johnson: Simon N.: That is a reasonable position to take. I think it will encourage interoperability without requiring it, and without laying down a mandatory protocol.
Eric Johnson: Anish: We're really talking about creating a spec - if you're using binding.ws & using SOAP - it is up to the TC to say what the right thing is to do. Not arguing that the TC should say that this is *the* way, rather than *one* way. If it isn't in scope, we have a problem we could change the charter.
Eric Johnson: Mike E: There will be other ways of doing things. This is certainly within the scope of the TC, but unwise to say this is the only way to do it. Just an example, I think this is what we've agreed before.
Eric Johnson: Simon H: We have previously agreed that this would be an example.
Eric Johnson: Mike E: This gives us a way to prove that it *can* be done. We at least prove that it is implementable.
Eric Johnson: Anish: We could do either. If it is just one way to do this, then we have additional metadata that flags which way is being used.
Eric Johnson: ... even if it is a way to do callbacks. A non SCA system that only understands WSDL and WS-Addressing, could also interoperate with an SCA service that does this. I think making a separate spec would enable that. Not sure why we would want to bundle this into a section of binding.ws, rather than a separate specification. Smells and looks and feels like another WS-* spec.
Eric Johnson: ... if that is the case, why not call it that?
Eric Johnson: Mike E: Why do you want to go there?
Eric Johnson: Anish: Understand the difficulty of doing another WS-* spec.
Eric Johnson: ... but we are absolutely creating another one of those spec.
Eric Johnson: Simon N: If we do that, we increase the scope, other cases that are beyond what SCA needs. Many reasons why the clause was put in the charter. How much do we really want to take on creating another WS-* spec?
Eric Johnson: Tom R: Are you saying that this could be used for any callback notion, not tied to SCA?
Eric Johnson: Anish: If you add an extension to WSDL, and you understand that extension - then that tells you how to send stuff on the wire to achieve interoperability.
Do want to respond to Simon - are you saying we might find additional work?
Eric Johnson: Simon N: It simply has to be more work than writing a section in the SCA spec. Presumably you'd have to get people in from the other communities, and that will vastly increase the scope of work.
Eric Johnson: Anish: Certainly there are things like security considerations that we might need to add. But if we want this to be interoperable...?
Eric Johnson: Simon N: If we do an example of how to do this, then after the 1.1 version we could explore mandating an approach if it is adopted.
Eric Johnson: Anish: Did you mean example or optional?
Eric Johnson: Simon N: Don't think we should under-specify. Should do a complete example, 80-90% of use cases. If we're on the example track, there are cases you can ignore.
Eric Johnson: Simon H: Drawing discussion to a close.
Eric Johnson: ... issue as it is currently stated is around providing an example.
Eric Johnson: (Scribe note - early references to "Simon" without qualification are all to Simon Holdsworth.)