See also: IRC log
<trackbot> Date: 30 September 2008
<Phil> Zakim IBM is Phil
<markphillips> Scribe: Eric
mark: phil please talk us through text message.
phil: Agreeing with Eric that we
don't need to explicitly say in the SOAP/JMS binding spec how a
client would be told to use a bytes message or a text
... instead we can be vague and leave it up to the vendor runtime to determine that.
... also no changes needed in the URI scheme for the purposes of text messages.
... If we're going to leave it up to the vendors, then it doesn't make sense to change the URI scheme - at least nothing additional in the spec.
... suggested changes are in the email linked to above.
mark: we should get agreement on the call today, and then check with people who are not here.
Amy: no objections
Derek: no objections so far. Want to read it over again.
eric: no objections
mark: mark no objections
phil: no objections
Yves: as long as we achieve interoperability.
action Mark to send out a note to confirm that Glen, Bhakti, Roland have no objections.
<trackbot> Sorry, amibiguous username (more than one match) - Mark
<trackbot> Try using a different identifier, such as family name or username (eg. mhapner, mphillip)
action markphillips to send out a note to confirm that Glen, Bhakti, Roland have no objections.
<trackbot> Sorry, couldn't find user - markphillips
action mphillips to send out a note to confirm that Glen, Bhakti, Roland have no objections.
<trackbot> Sorry, couldn't find user - mphillips
eric: Do need to clarify some of the details of the use of text message.
action eric to write up details around the use of text message, specifically addressing the "encoding" element in XML, the increased size as a consequence of base64 encoding.
<trackbot> Created ACTION-36 - Write up details around the use of text message, specifically addressing the \"encoding\" element in XML, the increased size as a consequence of base64 encoding. [on Eric Johnson - due 2008-10-07].
<markphillips> action mphillip to send out a note to confirm that Glen, Bhakti, Roland have no objections.
action "Mark Phillips" to send out a note to confirm that Glen, Bhakti, Roland have no objections.
peter: think we perhaps should standardize the flagging of which message type to use in the WSDL, it would increase interoperability.
phil: Not sure why we wouldn't go to also carry the details in the URI.
eric: Yes, but JMS URI is used in non SOAP-JMS cases, and if we added messagetype to URI in its full generality, there are a lot of message types we need to cover for which we don't have use cases.
phil: we don't require the use of WSDL, doesn't that make it compelling to put it in both places.
peter: Yes, but we're not just talking about programmatic use, even inspection by humans has value.
mark: don't we have properties that are not in the URI spec, but that are in the SOAP binding spec as details to be carried in the URI.
phil: OK with not specifying it in either place.
eric: Note that specifying the message type does not have any affect on the quality of service
<Yves> is the API abe to use _transfer encoding_ at the HTTP level? (at the application level, it should be transparent), so I guess the discussion is more on the possible encodings returned in Content-Encoding
mark: I guess we did already specify that a server must respond in kind to text/bytes message.
phil: If we're going to put a binary message in a string, then we have to do base-64 encoding, don't we.
Yves: yes - if it is a JPEG, then you would have to use base64....
Phil: we don't want to have to use base64, but if that is what the user requests, then that's what we should deliver.
Amy: base64 is remarkably
inefficient in UTF-16 - and the JMS API uses String....
... also note that there is a security issue here that this could consume large amounts of memory....
mark: eric should include the discussion here into writeup on TextMessage.
phil: incumbent on runtime vendors to document how to use TextMessage, and why to avoid it.... Need to give the customers the tools to decide.
Amy: incumbent upon us note in the specification that the bloat may disappear on the network, but will still have it in memory.
phil: not sure about the security implications.
amy: enormous leverage for denial of service - memory is a constrained resource in comparison to network bandwidth.
eric: I can do a write-up on the discussion around text message, and then responses to that...
phil: can live with putting indicator in WSDL for text message as documentation.
action peaston to write up how to indicate use of text message in WSDL.
<trackbot> Created ACTION-37 - Write up how to indicate use of text message in WSDL. [on Peter Easton - due 2008-10-07].
peaston: His take is that the WSDL section is not normative.
eric: do you care if it is
... my point is that I interpreted it as optional, but normative.
peaston: making it non-normative would be somewhat redundant - probably shouldn't allow "cafeteria style" approach to WSDL portion of specification.
phil: what is "normative"?
alewis: the informative sections
of the specification are always trumped by the "normative"
... making certain that what you write in the normative sections must be both implementable and unambiguous.
... what we've got is much more like a "profile". What we've got are four profiles: SOAP, SOAP + WSDL 1.1, SOAP + WSDL 2.0, SOAP + WSDL 1.1 & 2.0
... if you're claiming conformance - the WSDL 1.1 & 2.0 sections are normative.
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Eric Inferring ScribeNick: eric WARNING: No "Present: ... " found! Possibly Present: Derek IBM Peter_Easton Phil TIBCO WS_SOAP-JM Yves aabb aacc active alewis amy eric joined mark markphillips peaston peter soap-jms trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Roland Agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2008Sep/0036.html Found Date: 30 Sep 2008 Guessing minutes URL: http://www.w3.org/2008/09/30-soap-jms-minutes.html People with action items:[End of scribe.perl diagnostic output]