OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Since I didn't see anyone else capture the minutes:

Here's the raw chat:

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 

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: 

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 

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 

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 

"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 

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 

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 

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 

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 

WSDL 2.0 support 
Raiser: Bryan Aupperle, owner: Editors 
Status: Proposal in issue 

Add a section documenting naming convention + be consistent on naming intents (binding.ws) 
Raiser: Anish Karmarkar, owner: Editors 
Status: Proposal in issue 

Add a section documenting naming convention + be consistent on naming intents (binding.jca) 
Raiser: Anish Karmarkar, owner: Editors 
Status: Proposal in issue 

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: 

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 

JMS callback specification does not cater for callbacks using other bindings 
Raiser: Simon Holdsworth, owner Simon Holdsworth 
Status: Complete resolution proposal required 

Update binding.ws spec for wireFormat/operationSelection elements 
Raiser: Simon Holdsworth, owner: Anish Karmarkar 
Status: Specific resolution text required. 

Update binding.jca spec for wireFormat/operationSelection elements 
Raiser: Simon Holdsworth, owner: Piotr Przybylski 
Status: Specific resolution text required. 

Endpoint URI algorithm is unclear 
Raiser: Eric Johnson, owner: Eric Johnson 
Status: Initial proposal in JIRA. 

Open issues with no identified resolution owner: 

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 

@wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs 
Raiser: Eric Johnson 
Status: Specific resolution text required 

Which wire did a message arrive on? 
Raiser: Sanjay Patil 
Status: Waiting for examples from Sanjay as per 20080717-4 

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 

Properties on Bindings 
Raiser: Piotr Przybylski 
Status: No current proposal; defer until Policy 15 (External Attachment) is resolved 

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 : Action Items:
Martin C : 20081201-4: Done
Martin C : no new issues
Martin C : Topic: issues discussion
Simon Holdsworth: Latest combined proposal in http://lists.oasis-open.org/archives/sca-bindings/200812/msg00041.html
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: uuid URIs
anish: very easy
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
Dave Booz: +1 to Mike E
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
Martin C : motion passes
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
Martin C : section 3:
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:
Simon Holdsworth: If the related request message did not contain the wsa:MessageID SOAP header block, the SCA runtime MUST NOT include a wsa:RelatesTo SOAP header block with a relationship type value of "http://docs.oasis-open.org/opencsa/sca-bindings/ws/callback/200812" in the callback message.
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 : back
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 : 2nd Mike E
Martin C : passed w/o
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 : s/of/if/
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 : s/is/are/
Martin C : Motion: Ashok: move that the last sentence in para 3 be removed
Martin C : Anish 2nds
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:
Simon Nash: If the related request message did not contain the wsa:MessageID SOAP header block, the SCA runtime MUST NOT include a wsa:RelatesTo SOAP header block in the callback message with a relationship type value of "http://docs.oasis-open.org/opencsa/sca-bindings/ws/callback/200812".
Martin C : Tom R 2nds
Martin C : amendment passes w/o
Martin C : Motion now readS: replace last sentence with "If the related request message did not contain the wsa:MessageID SOAP header block, the SCA runtime MUST NOT include a wsa:RelatesTo SOAP header block in the callback message with a relationship type value of "http://docs.oasis-open.org/opencsa/sca-bindings/ws/callback/200812".

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: meeting is recessed until 7am PT tomorrow

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]