W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2004

Minutes, 20 May 2004 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 24 May 2004 21:49:33 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203B6C8B0@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 20 May 2004
New York City, hosted by IBM.

Thursday 20 May

 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Amelia Lewis           TIBCO
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Jerry Thrasher         Lexmark
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

 Tom Jordahl            Macromedia
 Hao He                 Thomson 
 Kevin Canyang Liu      SAP
scribe: Amy
08:15 Issue 54: Allow binding to any HTTP method [20]
  - Hugo's original proposal [21]
  - DaveO's original proposal [22]
  - Hugo's combined proposal [23]

 [20] http://www.w3.org/2002/ws/desc/2/06/issues.html#x54
 [21] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0042.html
 [22] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0055.html
 [23] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0093.html

Hugo, "Full Potato" proposal.  Issue 54.

Define method attribute as string.  BNF for restrictions on method 
names.  pattern facet supplied.  Define inputSerialization, 
outputSerialization attributes.  methodDefault attribute on 
http:binding as currently defined.  Defines three MEPs: In, 
Robust In, In/Out.

Change from single attribute to set; now three.  Defaults are defined
to avoid creating work.

Arthur:   Could change default to application/x-www-form-urlencoded 
          or multipart/form-data.  This would permit use through 
Sanjiva:  Support default of application/xml.
Glen:     Who will use HTTP binding?
Arthur:   Post no more restrictive than get, using standard browser 
          media types.  Easier to obtain browser support with this 
          as default.
Bijan:    Wants "sugar" (syntax sugar) to make it easy to use both, 
          because current apps use about equal of both.
Hugo:     Continues, discussing restrictions on operation styles 
          associated with media types.  Examples.
General discussion.
Arthur, Jonathan: readable, easy.  Question of preferred media type.

Discussion of default inputSerialization.  Possibilities: text/xml, 
application/xml, application/x-www-form-urlencoded, 

Arthur:   History of preferred MIME types for XML and reasoning.

Discussion leads to split between those preferring type preferred 
by browsers versus those preferring application/XML (easier to 

Arthur:   Main use of HTTP binding is for web applications that are 
          accessible by web browser, so default to forms media type.
          As long as both are defined, though, it's just the matter 
          of what to optimize.

General call for straw poll.
  application/xml: 5;
  application/x-www-form-urlencoded: 7.

Glen:     default means using URL style.

Jonathan: Call for objections to adopting Hugo's proposal with 
          amended defaults.  No objections.  Accepted by consensus.  

RESOLUTION: Issue 54 closed, Hugo's full potato proposal accepted,
            with default changed to x-www-form-urlencoded.
ACTION: Editors to incorporate Hugo's full potato proposal.

Hugo: also closes Issue 147.

RESOLUTION: Issue 147 closed.

10:30 HTTP
  - [optimization] properties [24]:
    + HTTP Version
    + Content coding
    + Transfer Codings (Chunked encoding)
    + Caching (Vary, etc.)
    + Content Negotiation ?
  - David's original analysis [25]
  - David Content coding is more than optimization [26]

  - [client requirements] properties [27]:
    + Authentication (and related parameters)
    + SSL
    + Cookies
    + Content Negotiation ?
  - David's original analysis [28]
  - David's initial proposal [29]

 [24] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0019.html
 [25] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0083.html
 [26] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0027.html
 [27] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0020.html
 [28] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0083.html
 [29] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0030.html
Client Requirements for properties in the HTTP binding.  Proposal 
from David Orchard.  Reference to email (Subject: HTTP Properties V2).

Each of the properties has subtle differences from others.  
String/description versus complex types.

Properties, each.

"Accepts" property.
Sanjiva:  Where does this go?  
David:    May appear on either input or output, provides nearly 
Sanjiva:  Wants defaults, but means need separate defaults for inputs 
          and outputs.  On output message, "accepts" now means 
          something different (means "supports" or "emits").  
Umit:     How does this interact with media types document?  Looks 
          like conflict.
Glen:     Need to figure out how these work together.
Sanjiva:  Use this only for input, not for output (for output, this 
          is not "accepts").
David:    Okay, so how can the client specify output?  And how can 
          the server say, in the WSDL, what it can produce?
Sanjiva:  Then it's a different attribute.
Jonathan: I thought that this was to permit negotiation to be 
Sanjiva:  Fine, but this isn't "accepts," if it's what the server 
          may emit.  Reference to yesterday's argument.
Roberto:  Client can specify in header.
Sanjiva:  Yes, but having this in the WSDL means that client can 
          construct a more specific accepts header.  
Umit:     But this is defined in schema, by media types note.
Glen, Jonathan: require this note?
Roberto, Umit: use the note.
Jonathan: How does the abstract media type map to base64-encoded XML 
          versus actual binary stream?
Glen:     Have to have constraints on media types.
Roberto:  Why do we have this, inputSerialization, 
          outputSerialization, and the note?
Jonathan: If I already have the type in the schema and the 
          input/output serialization, why do I need this?
David:    Permits multiple media types?
Umit:     Note does.
Sanjiva:  Need HTTP content negotiation.  Question of whether the 
          note provides this functionality.
Umit:     All that needs to be done is that the binding needs to 
          reference the note.  
David Booth: Is this more complex than what we need?  For 
          human/browser interaction, negotiation needed; is it truly 
          needed for app/app?
Paul:     RSS counter-example for app/app content negotiation.
Sanjiva responds; generate the accepts header not from a new property,
          but from media types document.
Jonathan: Accepts property unnecessary?
Umit:     Need paragraph in HTTP binding to use media types document.
Allen:    Wasn't media types about attachments?
Sanjiva:  If it's multiple bits, you can use that, but you can also 
          do the single part type.
David Orchard: can I send a gif and get a jpeg?
Answer:   Yup, not hard.

ACTION: HTTP binding to be updated to include discussion of how to 
        generate an accepts header from schema annotations 
        conformant to the media types extension document, and to 
        use outputSerialization based on that information.  
Accepted by David Orchard.

Accepts property not accepted.

Authentication property.  Description by David Orchard.
Sanjiva:  Need a default value which has a different name.  
          Discussion of value of string.
Jonathan: Realm property is associated.  Take values from HTTP spec 
          and use them.
Sanjiva:  Realm has no default.
Amy:      Loud noises on how authentication is negotiated.  Suggest 
          that content of auth type is a prioritized list.  
Paul:     Shouldn't this be in endpoint?  If in binding, can't be 
          used with multiple deployments.
Amy:      Propose that this move to be an element inside 
Jonathan: Question on how realm is defined.
Amy:      Responds with how easily one machine can define multiple 
Sanjiva:  Why can't this be in the binding.
Arthur:   Because then the binding can't be reused.  Objections to 
          placing auth type on endpoints.
Hugo:     Does it go only on endpoint, or in multiple places?  Auth 
          type in binding, realm in endpoint.
David B:  Why not use features and properties?
Jeff:     Separate syntax from goals.  Does this belong in core?

Cookies property.
Umit:     This attribute informs the client that cookies must be 
          enabled, right?
David:    Better be prepared to accept cookies.
Roberto:  What help does this give me as a service writer?
Answer:   None, it only helps the client to know.
Paul:     Single sign on example.
Roberto:  Why so low level?
Jeff:     All properties are requirements from the service; don't 
          change the need to program service defensively.  Clients 
          can always ignore this.
Roberto:  That's not my argument.  How does indicating that the 
          mechanism exists help?
Jeff:     Forget what cookies are used for.  This tells people that 
          the browser must have cookies enabled.
Paul:     Choice of bindings.
Amy:      Simply indicates mechanism, provides easier diagnosis.
Asir:     What's the relationship between cookies and bindings?  
Roberto:  Should define "conversation feature".
David:    That doesn't help any; we still need to know the mechanism.
Hugo:     Is requirement sufficient, given ability to use different 
          sites and do tracking and such?
Sanjiva:  Doesn't make sense on a single operation.  So you need to 
          say something more complex.
Amy, Umit, David: no, you just say, "you must support cookies."
Prasad:   Not just about conversation; useful to support at this 
David B:  Which cookies get sent back?
David O:  There is a spec that tells you this!
David B:  How does the "only this domain" setting in a browser works?
David O:  You have to match the domain.
Amy:      More explanation of how tracking works.
Roberto:  Compare with session handling in SOAP.  Can apply to other 
          services in the same domain.  Doesn't help the client at 
David O:  Three cases: not indicated; client breaks without cookies.
          Isn't WSDL supposed to prevent this case?  Case two: says 
          "I require cookies".  Case three: provide two bindings, 
          one with, and one without.
Roberto:  Completely unnecessary.
Arthur:   WSDL describes interfaces, not semantics.
David O:  What is the alternative proposal?  Move it into the 
Jonathan: Can I use it on operations?  (no)
David B:  Becomes significant at application level, agrees with 
Glen:     So what?  Sure, it's application significant, but that's 
          the way that it works in the real world.  It is not 
          necessary to promote this into the interface.
Roberto:  If there is something that is being passed back and forth, 
          it ought to appear as a feature in the interface.
Glen:     Can define a feature for state, but this is just a mechanism
          that could fulfill it.
David B:  What would happen without this?
Amy:      Likely to be requirement for authors using this binding.

Straw poll: in favor of cookies: 12.  opposed: 5.

Hugo:     Don't want to encourage cookie use.
David O:  This argument is without merit, although it is a canon of 
          W3C.  In practice, state is important to a broad spectrum 
          of applications.

10:30 Break     ----------------------------------------

10:45 HTTP properties (cont.)

Transfer-coding attribute.
David O:  Same kinds of problems as the accepts property, given that 
          it is for both directions.
Umit:     What is use case?  Require input or output to be gzipped 
          because of high volume?
David O:  For input, difficult to say "send as gzip."  For instance, 
          repeatedly invoked operation.  Another instance is complex 
          work flow; where stuff is sent on different operations.  
          Latter case is more significant, because it's not possible 
          to optimize in HTTP.
Sanjiva:  Actually, can't negotiate this one; only way to do it is to 
          try it and fail.
Umit:     Isn't this about requirements?  Want to advertise as a 
Youenn:   Isn't a requirement, just advertises availability.
Umit:     Better if it's a requirement.  Better to make it a 
David:    Again a case of split bindings?
Sanjiva:  Can't really be requirement.
Umit:     See main value when it is a requirement.
Sanjiva:  Better in this case to be availability.
David:    To take to extreme, every one of these attributes can be 
          divided into supported/required.
Umit:     For cases that can be negotiated, then it is enough to 
          provide a "required" attribute.  For cases that can't be, 
          have both attributes.
Amy:      Different cases for input and output: input is supported 
          possibilities, output is required.  
Sanjiva:  Is it really useful for output?  Negotiate by using 
          separate bindings?
Asir:     Interaction with HTTP version: for 1.0 cannot use 
          transfer-coding at all.
Sanjiva:  Perhaps not useful on output?  Tie input to output?  Make 
          it input only.
David:    But use of multiple bindings would permit client choice.
Sanjiva:  No, only interesting for service to say supported or not.
          We should only do this on input.
Amy:      Is this an endpoint property?
Sanjiva:  Should we use it input only, as supported, as required?
Amy:      Tying input to output not good; asymmetry in 
Sanjiva, Umit: Don't have transfer-coding negotiation.
David:    Can add that capability by using different bindings.
Asir:     See RFC 2616 14.39 for transfer-coding negotiation using 
          the TE header.
Where does this go?  Endpoint, binding, elsewhere?  Accepted (?), 
appearing on binding, operation, and input/output, only appears in 
component model for input/output.
Amy:      Can this also appear on faults?

Header property.
Optional element with required isOptional attribute.
David O:  Straw man proposal.  Use cases like Depth header.  
Amy:      Propose binding ADD to HTTP.
Sanjiva:  Fold issue into ADD issue.
Header property rejected.

Proposal: no accepts, header properties.  Accept cookies, 
          transfer-coding.  Accept AuthenticationRealm, 
          AuthenticationType with modifications to provide 
          fallback.  HTTP version property to be added.

Umit:     Question on optimization and negotiation.
David O:  Already accepted as an action.
David:    Propose to rewrite.
Jonathan: Could even be editorial task.
Hugo:     Some comments earlier on setting transfer-coding based on 
          URL.  Shouldn't we allow on endpoint?  Reaction: we're not 
          talking about where it appears, we're talking about whether 
          we accept the properties.
Jonathan: Does cookies stand out like sore thumb?
Umit:     Is SOAP layering to be discussed separately.
Answer: yes.

Consensus: accept five properties.

Jonathan: authtype on binding, operation.  version on endpoint, 
Objections: version goes on binding, because it influences other 
          things.  Cookies on binding only.  transfer-coding appears 
          on binding, operation, messages, but in component model only 
          on messages.
Hugo:     Objection, isn't this an optimization that ought to appear 
          on the endpoint?
Youenn:   Some servers don't support chunked input, do support output.

Jonathan: Making grid for location of properties.

EBOI = Endpoint, Binding, Operation, Input/Output
       (lower case=defaulting syntax).
E    AuthenticationType
E    AuthenticationRealm
 B   Cookies
 boI Transfer-Coding
 B   Version

Discussion of AuthenticationType location, starting with EBO.
Asir & Amy: endpoint only.
Umit:     Need it in binding for code generation.
Sanjiva:  This is plugin code, not generated code.  
Resolved to place only on endpoint.

Transfer-Coding discussion: optimization, belongs on endpoint.  
Youenn:   Some servers need ability to distinguish between input and 
Paul:     What's use case?
Youenn:   Repeats that servers do distinguish between input and 
          output.  Argument about whether chunked is universally 
          supported or not.
Hugo:     Optimization, on endpoint.
Youenn:   Need in and out separation.
Amy:      Server supports or not.
Straw Poll: endpoint only versus boI.  Endpoint: 5.  boI: 5.
Second straw poll: 6 to 4, boI.

Argument about location of Cookies property.
Roberto:  Place Cookies on endpoint rather than binding.  
Sanjiva:  This makes no sense, it will never happen that way.  
Endpoint level: 2.  Binding: massively more.

RESOLUTION: add http:authenticationType, http:authenticationRealm
            to endpoint, http:cookies and http:version to binding,
            and http:transfer-coding to input/output (with defaulting
            at binding and operation).
ACTION:   Editors to incorporate decisions into binding.

Drafting more editors.  David Orchard offers to join as editor of 
part 3.  Accepted as editor.  Philippe has resigned as editor.  
Hugo available as support and backup.

  - Issue closures:
    + Issue 165: Adding HTTPS support [30]
    + Issue 147: HTTP binding uses static content-type header [31]
    + Issue 55: Define binding to HTTP headers [32]
    + Issue 56: Define means to specify an authentication
                requirement [33]
    + Issue 164: Support for HTTP chunking and other HTTP 
                 options [34]

 [30] http://www.w3.org/2002/ws/desc/2/06/issues.html#x165
 [31] http://www.w3.org/2002/ws/desc/2/06/issues.html#x147
 [32] http://www.w3.org/2002/ws/desc/2/06/issues.html#x55
 [33] http://www.w3.org/2002/ws/desc/2/06/issues.html#x56
 [34] http://www.w3.org/2002/ws/desc/2/06/issues.html#x164

RESOLUTION: Close issues: 165, 147, 56, and 164 as addressed by this
            proposal.  Leave 55 open until we get to ADD.

Next meeting: 8:00 Friday morning.

12:00 Adjourn
Received on Tuesday, 25 May 2004 01:03:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:40 UTC