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
Simon Holdsworth: Agenda:
Simon Holdsworth: 1. Opening
Introductions
Roll call
Scribe assignment
Top 10 on the scribe list:
Nimish Hathalia TIBCO Software Inc.
Plamen Pavlov SAP AG
Laurent Domenech TIBCO Software Inc.
Piotr Przybylski IBM
Anish Karmarkar Oracle Corporation
Martin Chapman Oracle Corporation
Simon Nash Individual
Tom Rutt Fujitsu Limited
Eric Johnson TIBCO Software Inc.
Ashok Malhotra Oracle Corporation
Agenda bashing
2. Actions
Check status of any actions opened on previous call
20081201-4 [Piotr Przybylski] Amend binding.jca spec to include all the listed updates except text for issue 45
3. 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)
Process any new issues opened on previous call
No additional new issues
4. Open Issue Discussion
Continue discussing issue resolutions.
Note that from a scheduling point of view, each issue is limited to 1 hour of discussion on today's agenda. Any unresolved issues will be carried over to the next day.
Open issues with proposed resolutions:
http://www.osoa.org/jira/browse/BINDINGS-53
JCA Binding needs RFC 2119 language
Raiser: Dave Booz, owner: Editors
Status: Current proposed text in http://www.oasis-open.org/committees/download.php/30260/sca-binding-jca-1.1-spec-cd01-rev3.doc
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/200810/msg00088.html Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00037.html
http://www.osoa.org/jira/browse/BINDINGS-7
JMS bindingType and ordered intent - clarification needed
Raiser: Peter Peshev, owner Simon Holdsworth
Status: Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00005.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/200811/msg00071.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 http://lists.oasis-open.org/archives/sca-bindings/200812/msg00027.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/200812/msg00028.html
http://www.osoa.org/jira/browse/BINDINGS-42
Clarify default data binding for JMS
Raiser: Simon Holdsworth, owner: Simon Holdsworth
Status: Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00007.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
http://www.osoa.org/jira/browse/BINDINGS-55
WSDL 2.0 support
Raiser: Bryan Aupperle, owner: Editors
Status: Proposal in issue
http://www.osoa.org/jira/browse/BINDINGS-57
Add a section documenting naming convention + be consistent on naming intents (binding.ws)
Raiser: Anish Karmarkar, owner: Editors
Status: Proposal in issue
http://www.osoa.org/jira/browse/BINDINGS-58
Add a section documenting naming convention + be consistent on naming intents (binding.jca)
Raiser: Anish Karmarkar, owner: Editors
Status: Proposal in issue
http://www.osoa.org/jira/browse/BINDINGS-59
Add a section documenting naming convention + be consistent on naming intents (binding.jms)
Raiser: Anish Karmarkar, owner: Editors
Status: Proposal in issue
Open issues with identified resolution owner:
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-39
JMS callback specification does not cater for callbacks using other bindings
Raiser: Simon Holdsworth, owner Simon Holdsworth
Status: Complete resolution proposal required
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.
http://www.osoa.org/jira/browse/BINDINGS-54
Endpoint URI algorithm is unclear
Raiser: Eric Johnson, owner: Eric Johnson
Status: Initial proposal in JIRA.
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
http://www.osoa.org/jira/browse/BINDINGS-48
How are mayProvide intents on bindings satisfied
Raiser: Ashok Malhotra
Status: No current proposal; latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00041.html
6. AOB
-------------------------------------------------------------------
Dave Booz got a busy signal a few times before the finally getting into the call
anonymous morphed into anish
anish getting a busy signal too
Ashok Ashok: I had the same problem
Martin C : scribe: Martin C
anish got in, keep trying ashok
Martin C : 20081201-4: Done
Martin C : Topic: issues discussion
Martin C : Simon goes over the mail
anish: 1)If the request message contains the wsa:From SOAP header block, then it specifies the Callback EPR.
Martin C : Simon H: do we have to talk in turns of SCA Runtime and not messages for conformance
Martin C : s/turns/terms/
Mike Edwards: The emeeting URI is:
Mike Edwards: I can hand ownership of the pen to anyone...
anish: i don't think this is going to be the final text, we are going to edit this now and it is going to change when it goes in
Mike Edwards: ok, then lets capture the main points that the new text must deal with
Mike Edwards: 1) SCA Client requirements
Mike Edwards: 2) SCA Service side requirements
anish btw, i intended this proposal for getting direction
Mike Edwards: I think we are v close on the direction
anish: 
Martin C the scribe is lost but sure no decision has been made yet
Martin C : discussion about what non-sca clients should do.
Martin C : Anish: a basic ws stack with ws-addressing should aupport this
Mike Edwards: we're spending a large amount of time discussing a relatively small point
Mike Edwards: I'm minded to make a directional motion to get this decided and enable us to move on
Martin C : Anish: defining a protocol. both sides need to understand this
Mike Edwards: Motion: That the direction is set for the resolution of Issue 2 so that the MessageID field is optional on the request message from the client to the service but that if present, it must be returned in a RelatesTo header in a callback request from the service to the client
Martin C : Mike E Motions as above: Dave B 2nds
Martin C : Anish: speaks against motion
Martin C : Vote: 6 Y, 4 N, 0 A
Simon Nash: i have the live meeting client going... just seeing a blank screen
Martin C : Tom: an example would help to clarify who needs to decide what, whether message id is there or not
Simon Nash: should I see a document there?
Martin C : nothing is being dsiplayed
Martin C : Simon H: ack that explanitory text will be required, lets focus on concepts
Tom Rutt (Fujitsu): rough cut at intro to item 2): If the invoker of the request operation has a need to have the callback correlated to an individual request message, it can use the messageID for this purpose.
Martin C : Anish: there can be multiple relates-to, which can support higher level MEPs. therefore should never say relates-to should not be present
Martin C : are we re-designing ws-adressing?
Simon Holdsworth: Possible modification to the last sentence:
Mike Edwards: ok, +1 to Anish
Martin C : scribe needs a 2 second bio break
Mike Edwards: I'll cover for you Martin
Martin C : though this is a hard discission to follow/minute
Mike Edwards: we are spending an incredible amount of time over something that is of very little impact
Mike Edwards: again I am minded to make a motion just to close the discussion
Eric Johnson: I'm about to.
anish: me 2, but since there is a Q ...
Martin C : Eric: moves to limits discission for issue 2 for another 15 mins max
Martin C : stop at 30 mins passed this hour
anish: The proposal would be: in v5a remove the last sentence in (3)
Martin C : Tom: has to be a message id. do we say what its form/semantics is?
Martin C : Mike E: the reponse message contains the message id fromn the forward message
Martin C : Simon H: what of there isnt one in the request
Martin C : Simon N: talking about the semantics of sca relates to and should be very prcise
Martin C : Ashok: an sca relates-to is overkill
Martin C : Anish: there could be higher level agreements that wont have to use this new relates to type
Martin C : Simon H: this wouldnt be sca ws-callback then
Mike Edwards: can I suggest that we ensure that we have discussed all the points
Mike Edwards: rather than ratholing on this one??
Martin C : Eric: for ease of conformance we are putting the pressure back on the client, which was one of anish's goal
Martin C : debate is if there is no message id on outbound, what is the restrictions in the inbound relates-to?
Martin C : Motion: Ashok: move that the last sentence in para 3 be removed
Ashok: Motion to remove : If the related request message did not contain the wsa:MessageID SOAP header block, the SCA runtime SHOULD NOT include a wsa:RelatesTo SOAP header block in the callback message.
Martin C : Simon N: moves to ammend:
Martin C : amendment passes w/o
Martin C : Motion passes w/o
Simon Nash: Simon Nash: scribe
Simon Nash: discussion about whether we are ready for final text to resolve issue 2
Simon Nash: action Anish: post proposal 6 with changes agreed today
Simon Nash: plus the words typed in to the chat room by Tom
Simon Holdsworth Re-dialled, hopefully people will get back in without problems
Simon Nash: back to BINDINGS-53
Simon Nash: Piotr has posted an updated draft
Simon Nash: line 140: "may be obtained" should say "can be obtained"
Simon Nash: line 214: The binding.jca element contains a connectionInfo attribute .....
Simon Nash: action Piotr: produce another revision with above changes
Simon Nash: next issue: BINDINGS-7
Simon Nash: policy issue has recolved how the ordering should work
Simon Nash: s/recolved/resolved/
Simon Nash: Simon proposes adding a new paragraph that says where the intents are defined
Simon Nash: s/Simon/SimonH/
Simon Nash: issue 48 (mayProvides) may alter the text in this section
Simon Nash: motion Dave, seconded Eric: accept proposal in email from agenda
Simon Nash: motion is to resolve BINDINGS-7
Simon Nash: motion passes uninanimously
Simon Nash: next issue: BINDINGS-11
Dave Booz thanks Eric for consolidating the threads on issue 11
Simon Nash: It is possible to have both the soap and soap.1_1 intents
Simon Nash: The last sentence of the intro section should not have MUST conformance
Simon Nash: 4.2.1 first sentence has lower-case "must"
Simon Nash: should be changed to some other word TBD
Simon Nash: fifth bullet of 4.2.2 has lower-case must - should be capitalized
anish: s/document-lteral/document-literal/
Simon Nash: for fifth bullet, can use direct cross-reference to structural URI for binding as defined by issue 16 resolution
Simon Nash: for seventh bullet, the word optional should be removed
Simon Nash: in last bullet, should say All WSDL message parts
Simon Nash: second bullet, change "support" to "generate bindings for"
Simon Nash: and remove section 4.2.3 altogether
Simon Nash: Section 4.2 should be called "Default Transport Binding Rules"
Simon Nash: to clarify that it's not talking about the SCA binding
Simon Nash: it's a constraint on the SOAP messages
Simon Nash: this constraint may imply a similar constraint on a WSDL binding, if there is one
Simon Nash: may want to fold section 4.3 into somewhere under section 4.2 (e.g., 4.2.1)
Simon Nash: for the default binding case, the service's interface must be converted into a portType
Simon Nash: and that portType must follow the rules in 4.2.1
Simon Nash: if the service's interface is interface.wsdl, the "converted" result is identical to the original
Simon Nash: if it is some other kind of interface, it's converted into WSDL using the interface language's mapping rules
Martin C has to drop for another call. "see" you tomorrow
Simon Nash: as defined by the relevant SCA specification
Mike Edwards: I'd be ok with beefing up the "mappable to WSDL" wording in Assembly to state that an actual (and unique) mapping must exist for any interface used for a remotable service
Simon Nash: section 4.3 doesn't have a conformance target for MUST
Simon Nash: action Eric: look at 4.3 and see if the statement about mapping should be moved to some other place in the Web service binding specification
Simon Nash: action Eric: need to state the conformance targets
Simon Nash: for the namespace, Eric suggests using the structural URI for the service
Simon Nash: action Anish: check whether this must be an http: namespace so that the wsdl can be found at a "....?wsdl" URI
Simon Nash: last line: replace "should be" with "is"
Simon Nash: Mike: terms like "name of binding" and "name of service" are ambiguous
anish: just checked on the ?wsdl issue, this is not a problem
Simon Nash: Mike suggests "value of @name attribute for the binding"
Simon Nash: action Eric: come back with solid proposal to resolve SINDINGS-11
Simon Nash: s/SINDINGS/BINDINGS/
Simon Nash: meeting is recessed until 7am PT tomorrow