- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 24 May 2004 21:49:33 -0700
- 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
-------------------------------------------------------
Present:
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.
Regrets:
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
browsers.
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,
multipart/form-data.
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
define).
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).
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0053.html
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
negotiation.
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
sidestepped.
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
wsdl:endpoint.
Jonathan: Question on how realm is defined.
Amy: Responds with how easily one machine can define multiple
realms.
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.
Responses.
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
level.
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
all.
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
interface?
Jonathan: Can I use it on operations? (no)
David B: Becomes significant at application level, agrees with
Roberto.
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
requirement.
Youenn: Isn't a requirement, just advertises availability.
Umit: Better if it's a requirement. Better to make it a
requirement.
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
request/response.
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,
authrealm.
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
output.
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