Minutes, 2 December 2004 WS Desc telcon

Web Services Description Working Group
Minutes, Telcon meeting 2nd December 2004

Present:
  Erik Ackerman          Lexmark
  David Booth            W3C
  Roberto Chinnici       Sun Microsystems
  Glen Daniels           Sonic Software
  Paul Downey            British Telecommunications
  Youenn Fablet          Canon
  Hugo Haas              W3C
  Anish Karmarkar        Oracle
  Amelia Lewis           TIBCO
  Kevin Canyang Liu      SAP
  Jonathan Marsh         Chair (Microsoft)
  Jean-Jacques Moreau    Canon
  David Orchard          BEA Systems
  Arthur Ryman           IBM
  Jerry Thrasher         Lexmark
  Asir Vedamuthu         webMethods
  Sanjiva Weerawarana    IBM
  Umit Yalcinalp         SAP
  Prasad Yendluri        webMethods, Inc.

Regrets:
  Tom Jordahl            Macromedia
  Jacek Kopecky          DERI
  Jeff Mischkinsky       Oracle
  Dale Moberg            Cyclone Commerce

Scribe: 
  Paul Downey

IRC: 
  http://www.w3.org/2004/12/02-ws-desc-irc#T17-36-04


Approval of Minutes

  Minutes of the 18th approved.
  No telcon last week (Thanksgiving in USA)

Action Item Review

  Arthur completed LC43 part 1
  Arthur completed LC34s

Administrivia

  Next F2F meeting in Melbourne, questionnaire now open:
  http://www.w3.org/2002/09/wbs/34041/WSD0501/


  Marsh: visitors from many countries only need an electronic visa

  Hugo: W3C Australian office may be able to send an invite.
    Those from countries that need one should contact me ASAP.

  Marsh: have put together a plan for good standing rules, 
    and will send it out soon.

  Kevin: is good standing a company or individual basis?

  Marsh: it's transferable between participants within a member company.

  Marsh: suggests cancelling telcons on 23rd and 30th of this month

  [sanjiva] +1!

  Marsh: 30th cancelled, 23rd task force meeting (byo "egg nog")
         [ http://en.wikipedia.org/wiki/Posset ]

LC29b 
  http://www.w3.org/2002/ws/desc/4/lc-issues/#LC29b


  Glen: same as LC18?

  Glen: [reads suggested text for 2.6.1 on SOAP modules and features]

  Marsh: take this back to the list

LC50
  http://www.w3.org/2002/ws/desc/4/lc-issues/#LC50

  Marsh: we had a spirited TF call last monday

  dbooth: everyone on the TF seemed to be in-sync on this one.
    on definition of 'node' TF (v) Sanjiva, similar apart from 1
    small detail in wording in-out pattern in the TF even if 
    reply is redirected (using replyTo) reply is supposed to go 
    back to originating 'node', but service should be aware of 
    this and generate a fault [if nodes differ]. if client wants reply 
    to be redirected to a different 'node' then it should use 
    a different MEP.

  Marsh: clarifies if client addresses the reply to a different place,
    then it is implicitly asserting that is the same 'node'

  Anish: is the binding allowed to put addition restrictions on a
     MEP?, eg. HTTP binding

  dbooth: yes, binding is more concrete than an abstraction

  Kevin: do we need another MEP to cover this alternate replyTo case?

  dbooth: if client uses existing in-out, client is asserting
    addressed alternate physical endpoint is the same 'node'

  Marsh: what do we need to do to our spec to clarify this?

  [discussion of relationship between binding and MEPs]

  Marsh: this is basically a change to the definition of 'node'

  Umit: not sufficient, we need to clarify if a particular binding
    governs all the messages that may be sent within the MEP

  Anish: [clarifies] whole binding applies to an operation, not just a
    single message. sender of in message cannot dynamically set the 
    binding for the out message

  Glen: unless an extension is in play

  Glen:  we can use ws-addressing to point these to other places of
    course, if we have an extension that references ws-addressing

  Umit: to what extent is replyTo able to change the binding, to
    designate a different address for the same binding that's OK

  [sanjiva] Please note that our current SOAP 1.2 binding does not 
    permit the wsoap:protocol to be set except for the entire binding.     
    (I thought someone said something different earlier 
    .. hence this note.)

  [asir] sanjiva, I heard that oo

  [asir] perhaps this new transport will be called as http-smtp transport

  Kevin: if i use SOAP/HTTP binding, then i shouldn't get the reply
    over SMTP

  [asir]
    or ht-smtp

  Glen: there is a timing issue between WSDL and WS-addressing, 
      we should be careful not to restrict ws-addressing

  Sanjiva: only so much WSDL can describe, silly for us to prevent
    80/20 case for ws-addressing - use HTTP to send request,
    replyTo references another URL. this may not fit in with SOAP MEP, 
    but is most common use-case for WS-addressing

  Umit: agreed, but people shouldn't be encouraged to abuse the WSDL
    description

  [sanjiva] umit: I understand what you're saying, but IMO its not 
    a good plan for us to restrict what kind of EPRs can be sent for 
    replyTo, FaultTo etc.

  Marsh: so, an extension in a binding is not allowed to swap protocols?

  Glen: that would be bad

  Umit: of course we can override anything with extensibility, but
    what is the underlying model?

  [dbooth]
    The key point is that a mandatory extension, such as WS-Addressing,
    *can* change the default semantics of the binding. If WS-Addressing
    or anything else requires something different to happen than what
    the WSDL 2.0 specification says, then it needs to be indicated as a
    required extension, so that the WSDL document will not be misunderstood.

  Glen: i would want to put in the WSDL which protocols i could accept

  dbooth: mandatory extensions can change default semantics of a
    binding, but needs to be indicated as a 'required' extension

  dbooth: The problem (in practice) is that in order to really do it
    properly, one would have to write extension syntax to say "I use
    ws-addr, my replyTo will use soap/http, my faultTo will use
    soap/smtp" etc. .. pretty damned complicated and unlikely to ever
    catch on. So in practice its not going to matter.

  Anish: you can define extensions for in-HTTP, out-SMTP, but unless
    the extension should say that addressing will override the binding
    [transport]

  [dbooth]
    I should have differentiated between service and client. GlenD is
    right that if the service supports the extension as an optional
    extension, then then client may use it or safely ignore it. 

  Glen: really need to see what the ws-addressing extension looks like

  Umit: we're still waiting for reply from XMLP on this issue

  Kevin: each endpoint can only be attached to one binding, right?

  Glen: unless an extension which modifies that rule is in play

  Anish: for such an extension, would 'required' have to be true?

  dbooth: no, could be optional and the client may choose to engage it
    if client sends replyTo back, then is indicating extension is in play

  [dbooth]
    Section 6.1.1 explains: [[ If a WSDL document declares an extension,
    Feature or Property as optional (i.e., NON-mandatory), then the
    provider agent MUST NOT assume that the requester agent supports
    that extension, Feature or Property, unless the provider agent knows
    (through some other means) that the requester agent has in fact
    elected to engage and support that extension, Feature or Property.]]

  Umit: why are we bothering with the MEP at all if it is so
    unconstrained?

  Glen: SOAP binding for WSDL a little wierd. SOAP binding talks about
    simple MEPs, but they don't map onto WSDL MEPs and then there are
    extensions in both ..

  Umit: then we should fix our SOAP binding, not loosen MEPs

  Kevin: spec not clear enough as it stands

  [scribe loses irc connection, meanwhile there is a discussion 
    over usefulness of bindings and MEPs in general if it is
    so open ended]

  dbooth: suggest that we add a note to clarify, 
      using WS Addressing as an example

  Sanjiva:  more than one way to describe a given set of
    messages on the wire

  [discussion of changes to component model]

  [sanjiva]
    I'm -1 for making a change to the component model to support
    ws-addressing type stuff. +1 to Glen's comment that use of ws-addr
    is a runtime override not a wsdl-time override.

  Kevin/Umit: you need to be able to supply a default transport for a
    message, maybe a set of possible transports 

  Glen: and you'd probably need to select other stuff?

  Kevin: probably true

  Umit: dynamic exchanges of messages should be connected to WSDL
    description

  [dbooth]
    6.3: [[ Authors of extensibility elements should avoid altering the
    existing semantics in ways that are likely to confuse users.]]

  dbooth: meaning of WSDL is unclear (incomplete) if interactions
    don't match description. optional extension should indicate such
    behaviour

  [pauld] +1 to holding an obfuscated WSDL contest ..

  [sanjiva]
    +1 for do nothing. the editors have enough pending action items already.

  dbooth: should have a note 'optional extensions should be indicated
    in the WSDL'

  sanjiva: sounds redundant to me

  [sanjiva]
    ah yes - +1 to adding more stuff to our primer!!!!

  Kevin: suggests clear example for the primer to explain this use-case

  dbooth: spec should be clearer about if a runtime isn't going to
    directly match the runtime

  Glen: WSDL should describe the service!

  [sanjiva]
    -1 for taking this to email .. after having spent an hr I'd like to
    decide this rather than we push it to a lower-bandwidth medium

  [asir]
    +1 to Sanjiva

  sanjiva: want's a straw poll

  Marsh: informational straw poll - who is interested in this issue?

  [dbooth]
    Poll: Who is in favor of taking some kind of action on this issue
    (versus dropping without any action)?

  Marsh: many more 'yes' than 'no'

  [dbooth]
    ACTION: dbooth to draft note clarifying that (a) optional extension
    can change the semantics; and (b) that if semantics are going to
    change at runtime, it should be indicated in the WSDL

Received on Thursday, 2 December 2004 22:44:29 UTC