SOAP-JMS Binding Working Group Teleconference

 

 

<trackbot> Date: 03 February 2009

<peaston> I'm on the phone...

<peaston> yes

<scribe> scribe : mphillip

Actions

<Roland> http://www.w3.org/2002/ws/soapjms/tracker/actions/open

<scribe> No progress on actions 32 & 48

Action 53 is complete but material needs to be uploaded

<trackbot> Sorry, couldn't find user - 53

<Roland> http://www.w3.org/2002/ws/soapjms/wiki/2008-09_FAQ

close action-56

<trackbot> ACTION-56 Add answer to FAQ on how to use WSA anonymous and JMS ReplyTo closed

<scribe> agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2009Jan/0000.html

Peter: Question: I am familiar with WS-Addressing and how in HTTP you can specify a ReplyTo which is different from the requester.
... In any stack an error may occur. If we have a request where ReplyTo or FaultTo is another destination
... should we somehow define a behaviour if that reply or fault fails?

Amy: Anything to do with WSA is out of scope for us

Phil: It is up to the sender to make sure that the reply / fault address is available

Amy: Agreed - this would be defined in a WSA, SOAP/JMS binding extension if we were to write one

Roland: Have sent a response to Yong-Ping - currently out of office
... also sent response to 59 and 60

close ACTION-58

<trackbot> ACTION-58 Respond to Yong-Ping closed

close action-59

<trackbot> ACTION-59 Send email about LC-04 based on minutes from conf. call of Jan-27 closed

close action-60

<trackbot> ACTION-60 Respond with email saying that there is no fault. closed

Roland: Phil has written proposal for #61

close action-61

<trackbot> ACTION-61 Come up with a proposal to make sure we're consistent. closed

http://www.w3.org/mid/OF67177662.6FF6F762-ON8625754B.00692FA7-8625754B.006AED74%2540us.ibm.com

Phil: Recommend proposal #1

Derek: Agreed

Peter: +1

Roland: No disagreement - will send this as a response to Yong-Ping

resolution: Adopt Phil's first proposal - Phil to make changes

URI Spec

No update

Last call comments

<Roland> http://www.w3.org/2002/ws/soapjms/wiki/2009-01_LC_Comments

Comment #5 : http://lists.w3.org/Archives/Public/public-soap-jms/2009Jan/0008.html

relates to: 2.2.1 http://www.w3.org/TR/2008/WD-soapjms-20081121/#binding-connection

<peaston> stilol here

Q: Do all other properties defined in javax.naming.Context fit into the soapjms:jndiContextParameter category?

Peter: Believe the answer is yes - all values for the javax.naming.context go in these properties
... ...but is our specification not clear enough?

Eric: The jndi docs from the JDK has some possibilites for jndi initial context values

Peter: I proposed this originally

Roland: Can someone suggest some other examples

action Peter to Make a proposal to clarify the wording and scope of the (221) jndiContext Parameter property)

<trackbot> Created ACTION-62 - Make a proposal to clarify the wording and scope of the (221) jndiContext Parameter property) [on Peter Easton - due 2009-02-10].

Roland: Next comment from Phil - LC07: http://lists.w3.org/Archives/Public/public-soap-jms/2009Jan/0010.html

Phil: It's not really the place of the transport to specify the contentType
... The SOAP stack and the specifications it implements dictate this

Eric: There might be a simple phrase we can use "for example in the case of a message without attachments, one might use...x value for contentType"

Phil: Yes, the web service implementation determines the contentType (e.g. - might decide to use MIME messages for messages without attachments)

Eric: Yes, we should word this to be explicative rather than normative

All - review Phil's proposed wording

Eric: The revised wording must remove the normative contraints - needs to say in essense that the payload looks the same as an HTTP SOAP request
... In an HTTP request the payload is *part* of an MIME message (the HTTP header is also part of the message byte stream).
... In JMS the content type property does not need to be in the message payload - it can go in a JMS property
... So we are only referring to the MIME body part in the JMS message
... So there is a subtle difference between HTTP and JMS - the JMS API keeps the metadata seperate
... and in a JMS message the first part is the MIME boundary

Phil: So the content (body) of the HTTP message equates to the JMS message body

Peter: We have to think of the byte order marks

Amy: How does that equate to MIME?

<Roland> http://www.w3.org/TR/2008/WD-soapjms-20081121/#soap-request-with-attachments

Eric: Byte order would be a distraction

(discussion on XML declaration vs. HTTP headers for byte ordering)

Eric: Suggest that specific questions be handled over email

Roland: Who will start the discussion thread on this?

Eric: Liked most of Phil's proposal - suggested a specific revision

<Roland> http://lists.w3.org/Archives/Public/public-soap-jms/2009Jan/0015.html

Phil: WIll revise his proposal to start a discussion

Roland: Dongbo's comments
... We just said the jndi was required - do we need to explicitly say that queue and topic are not required

Eric: I don't think we need to clarify to that point

Roland: Agreed - believe spec is clear enough now

action Roland to respond to dongbo to say that the spec has been clarified re: IRI scheme jndi requirement

<trackbot> Created ACTION-63 - Respond to dongbo to say that the spec has been clarified re: IRI scheme jndi requirement [on Roland Merrick - due 2009-02-10].

Roland: Look at Dongbo's second comment offline and we will start with this next week - a small example may be worthwhile

Derek: re # 62 for peter I have found a standard property required by JBoss...

<Derek> java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

AOB

Peter: In the FAQ we should remove Bhakti's original wording