W3C

Web Services Addressing WG Face-to-Face Meeting

27 Feb 2005

Agenda

See also: IRC log

Attendees

Present
Rebecca Bergersen (IONA Technologies, Inc.)
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Philippe Le Hégaret (W3C)
Mark Little (Arjuna Technologies Ltd.)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (Computer Associates)
Greg Truty (IBM Corporation)
Steve Vinoski (IONA Technologies, Inc.)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Absent
Abbie Barbir (Nortel Networks)
Andreas Bjärlestam (ERICSSON)
Ugo Corda (SeeBeyond Technology Corporation)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Arun Gupta (Sun Microsystems, Inc.)
Yin-Leng Husband (HP)
Nilo Mitra (ERICSSON)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Harris Reynolds (webMethods, Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Pete Wenzel (SeeBeyond Technology Corporation)
Regrets
Martin Gudgin (Microsoft Corporation)
Chair
Mark Nottingham
Scribe
Jeff Mischkinsky
Rebecca Bergersen

Contents


Chair states the goal of this f2f is to have a LC draft; otherwise the W3C Team/AC will have to consider a charter extension

Chair reviews the agenda

glen: asynch tf prsentation will be done as part of issue 22

hopefully tues AM

Action item review

jmarsh fullfilled his AI on IRI, added after schema review

Approve Minutes

- 2005-02-21: <http://www.w3.org/2002/ws/addr/5/02/21-ws-addr-minutes.html>

RESOLUTION: approve minutes and post publicly - no objection

Schema publication

<http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr.xsd>

jmarsh: about to send a slightly revieed version with some tweaks...

Chair: how do we maintain this doc?

anish: someone noted that attribute extensibility is missing

jmarsh: have 5 modifications

glen: suggests putting up as an editor's draft and link to it from wg web page

Chair: its already in CVS.

anish: is schema normative?

<scribe> ACTION: MarkN to put up schema link on wg page [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

Chair: i032 resoluction says schema is normative.

jeffm: suggests making the schema take precedence in the case of ambiguity wrt prose

glen: prose captures semantics, often schema has small errors

more discussion back and forth -- jeffm should raise an issue of what happens if there is ambiguity

<Chair:> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0195.html

umit: does attr ext affect the bindings?

jmarsh: doesn't think so
... if you extend epr def, then beware -- not all processors will understand

umit: hasn't seen a good use case

jmarsh: mostly a consistency argumtent

<scribe> ACTION: marc h to add 1) to ed draft [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

<plh> ACTION 2=Marc Hadley to add attribute wildcards to ReferenceParamatersType and PoliciesType in the XML Schema

no objection to 2)

<scribe> ACTION: indicate that @RelationshipType defaults to [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

"http://www.w3.org/2005/02/addressing/reply" in the schema.

3) jmarsh not quite sure what the rationale is

4) same thing

<plh> ACTION 3=Marc Hadley to indicate that @RelationshipType defaults to "http://www.w3.org/2005/02/addressing/reply" in the schema.

5) pure consistency in nameing of types

<scribe> ACTION: marc h to change style so that type names end in Type - add "Type" to AttributedURI, AttributedQName, [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

FaultCodesOpenEnum, FaultCodes, AttributedNonNegativeInteger

URI/IRI

<hugo> Discussing: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0171.html

<scribe> ACTION: marc h to change style so that type names end in Type [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

jmarsh: the proposal details the exact changes

Chair: we already agreed to the general approach
... suggests that we should accept jmarsh's changes and then tweak as necessary

jmarsh: anyURI is seq of chars, when escaped appropriately (in XLink) it turns into a legal uri

using % and UTF 8

anish: is there a diff in the escaping mechanism in XLink and URI spec

jmarsh: doesn't think there is any difference
... XLink does describe the encoding for the escape mechanism
... URI spec doesn't describe the exact encoding

bob: notes the recent concern with IDN spoofing -- we might need to add some security comments

plh: not sure this is a concern for SOAP - the spoofing is a human readibilty concern when IDN chars are displayed in browsers

RESOLUTION: approve resolution in http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0171.html removing reference to RFC 3986

<scribe> ACTION: marc h incorpororate http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0171.html removing reference to RFC 3986 [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

break for 30 minutes: come back at 10:30 am

issue i004 -- Security Model

<http://www.w3.org/mid/DD35CC66F54D8248B6E04232892B633804D931FF@RED-MSG-43.redmond.corp.microsoft.com>

paco sent a friendly amendment

marcH: we should go further and provide more details

marcH: observes that expanding gudge's proposal to capture more details will make it simialr to what is already in there. Would like to understand what is new in gudge's proposal.

glen: the key issue is establishing trust -- and what mechanisms are used -- there are a variety

paco: may want to think about how to secure the epr itself, even when it is part of a trusted/secured message, if it is passed along by itself it will lose the security context

discussion of how to integrate gudge's proposal

other issues: where does security info end up -- general in abstract model, and then more specifics in the soap binding

jeffm: a bit vague -- lots of mays, coulds, etc.

glen: not our job to bind specifics

phl: expects that the WSDL will indicate specifics

Chair: we are building layered architecture -- this is base level

marcH: we should say things like when you use WS-Security use it "this" way

Chair: ways forward -- look at text in gudge's proposal, text in doc, and rationalize them
... when u use ws-addressing and ws-security specify how tha it is done

discuss of what pieces go where

march: as editor, need help to split the text and integrate -- no time between now and tues for me to do that work as well as incorporate all the resolutions from this meeting

<scribe> ACTION: hugo to integrate the current security text with gudge's and paco's new proposed text and split between docs and make a concrete proposal with exact text/location by tues [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

<Chair:> ACTION: hugo to integrate the current security text with gudge's and [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

<Chair:> +paco's new proposed text and split between docs and make a concrete proposal

<Chair:> +with exact text/location by tues

glen: we got a lot of the way there if we specify the abstract model

marcH: disagrees -- no need to go further

<Chair:> ACTION 6 = hugo to integrate the current security text with Gudge's and Paco's new proposed text and split between docs; make concrete proposal with exact text/location by tues

paul: concerned if we define the only way of doing stuff

marcH: wants to do specific scenarios to provide specific requirements

Chair proposes a straw poll: in favor of going down this road - 5 yes, 10 no, 5 abstain

umit, paul: concerns about time line

marcH: asking to provide some security guidance to alleviate possible problems with reply-to: and top level headers

paco: does that mean we could boil down the issue to more specifics

marcH: my emails are about specifics e.g. how do i establish the "trust" that the proposed language talks about

dHull: not sure this issue is really a ws-addressing level issue

davido: in general req/resp could go somewhere else, but we don't have any concrete way to talk about that level -- no arch doc to point at

Chair: does this approach mean selecting/developing scenarios and then providing the "cookbook" instructions on how to implement

dhull: want to see where the boundaries would be

<GlenD> glen: We talk about it in the abstract, and say "it's important to think about security and trust anyone who's sending you EPRs" - I just don't want us to get so specific right now. WS-Security (and other mechanisms) layer on top or below.

<umit> +1 to Glen.

tony: this sounds like a "profile", should be a sep doc

Chair: would it be acceptable to decouple this work?
... who would be interested in sep doc: 9 - 1 - 10

<mlpeel> +1 for separate doc

vote change: 11 - 1 - 9

Chair: can we close issue 4, assuming hugo's proposal is acceptable?

plh: may need a charter change

umit: why is this the case? we already have a security "charge" in the scope

hugo: it is debatable whether this is a change of scope.

Chair: putting aside the procedural issues for the moment, what would such a doc include?

hugo: there was some support for putting this in a separate doc, and for not including this in our current 3 docs that we are trying to close at this f2f

plh: Proposed Rec is the last time one can raise a formal objection

we will break for lunch at 12:20

issue 048 EPR comparison

<anish> http://www.w3.org/2002/ws/addr/wd-issues/#i048

umits proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0128.html

umit: preferred approach is to remove the section and add the words contained in her proposal (above) starting with "The following rule ...."

jeffm: pls clarify what is meant by "substitutable"

umit: essentially a client could use any of a set of substitutal eprs and expect the same thing to happen

jmarsh: not sure how the proposed text adds anything

anish: supports proposal for [2] - seems to clarify things
... does this proposal say anything about comparison of 2 EPRs

umit: comparison of EPRs is very much "in the eye of the beholder" Hence should be determined by the endpoint

anish: 2 EPRs that are the same, bit for bit - they are the same
... if there are 2 EPRS with some different data in them, they are not the same
... we can provide guidance for extensiblity points -- e.g. the order of children in an extensibility pt is irrelevant

hugo: doesn't see this proposal providing much of a clarification
... doesn't resolve issue 14

umit: not directly aimed at issue 14

paco: we should remove

davido: subsitution of EPRs - there is a matrix of choices depending upon whether the comparison returns true/fals
... at a min compar should look at the address field -
... uri spec contains some rules on how to "normalize" uri's for purposes of comparison
... each uri scheme can define additional rules for comparion -- e.g. http:

umit: the issue is EPR comparison, not uri comparison

<mlpeel> +1 to umit

paco: uri's are intended to be identifiers, after the issue 1 discussions, we decided not to go down the identifier "rathole"

anish: having additional txt that says that 2 EPRs with the same address but diff metadata are/could be different would be useful
... e.g. order of ref params is not relevant

steve: concerned hugo wants to keep section 2.3 as is

lunch break -- we will resume 1:45 (we hope)

<hugo> Scribe: Rebecca

<hugo> ScribeNick: RebeccaB

Poll on identity comparison: 1. remove section 2.3; 2: remove 2.3 + Umit clarifications; 3: Remove 2.3 + optional endpoint comparison function; 4: status quo

Umit: clarification in http:/lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0128.html "Proposal for (2)"

Discussion over wording of Umit's clarification

dhull: can't make assumptions about interchangability; we're not making any guarantees

GlenD: if get EPRs from different APIs, even if they are sytactically the same they may not have same semantics

discussion of role of context in identity relationship

<mlpeel> Variation on proposal 3: EPR minter adds an optional UUID element to its EPRs

<mlpeel> If a byte-by-byte comparison of UUIDs matches, the EPRs are identical

dhull: can't compare EPRs

<umit> What I/me i am amazed some people remember APL

Poll on identity comparison: 1. remove section 2.3 (out of scope?); \2: remove 2.3 + add Umit clarifications; 3: Remove 2.3 + add optional endpoint comparison operation; 4: status quo

dorchard: we should provide multiple useful comparison functions
... fifth option: Explore the space; Provide potentially multiple comparison functions
... agnostic as to whether 2.3 is included

hugo: people use 2.3 to interpret metadata's viability

viability = whether data has expired or not

dims: comparison operator needed for monitoring apps

marc_H: Burying head in sand if we pretend EPR is opaque

dhull: first: syntactic equality useful comparison; second: two EPRs pointing to same thing?; third: semantic equality
... if we talk about comparison from this point of view the discussion may be clearer

<umit> I think syntactic equality does not get us very far, as metadata may be stale, the extensions may appear in different order

dorchard: URI spec has definitions in place to clarify such differences

Anish: context builds up in course of interactions that allow one to interpret EPRs as they arrive in interactions. We can give guidelines or comparison functions for dealing with such occurences.

GlenD: why is it good to have to add additional info on top of everything else?

Paco: such operations domain specific

jeffm: want server-side comparison function

dhull, Chair: this is implementation of option #3

Poll on identity comparison: 1. remove section 2.3 (out of scope?); 2: remove 2.3 + add Umit clarifications; 3: Remove 2.3 + add EPR server-side endpoint comparison operation; 4: status quo; 5: Explore the space; potentially provide multiple client-side comparison functions

preference for #1: 14

Live with #1: 16

<mlpeel> Can live with #1

live with #2:

prefer #2 : 0

live with #2: 14

<mlpeel> I prefer #3

Prefer #3: 3

live with #3: 12

perfer #4: 2

live with #4: 6

live with #5: 17

prefer #5: 4

Live with #1: 17 (didn't get mpeel's vote)

<mlpeel> I can live with #1

Chair: clear preference for #1

discussion on whether it's necessary to explicitly say it's out of scope

consensus: not necessary to state

Anish: dropping 2.3 means re-opening issue 1 because 2.3 was used to distinguish EPRs when refprops no longer existed

GlenD: anything can be used to distinguish

Marc_H: Anish address + props identified endpoint; we removed props; now address + params identify endpoint

Actually poll was "Poll on EPR comparison", not "Poll on identity comparison" since we had declared that EPR doesn't deal with identity

"Identity" word came from text of 2.3

TomRutt: nothing tells you about comparison equality if refparam is different - ; response: nothing prevents app from making that judgement

Chair: worried about objections to putting text in spec saying we don't have comparison function

<bob> Siince this specification provides no concept of identity, this specification cannot provide any mechanism to determine equality or inequality of EPRs.

<GlenD> This does not mean that such mechanisms are forbidden - they would simply be designed for use within particular contexts.

<TonyR> Non-normatively, note that it is possible to provide a comparison function that is applicable within a limited scope.

<dorchard> I like the title: W3C Recommendation WS-Addressing WS-JustSayNoToIdentifiers

<dhull> "this specification does not provide any mechanism to determine equality or inequality of EPRs, nor does it specify the consequences of equality or inequality."

Vote on removal of section 2.3, replacing it with Bob's text: "Since this specification provides no concept of identity, this specifaction does not provide any mechanism to determine equality or inequality of EPRs, nor does it specify the consequences of equality or inequality. Note that it is possible to provide a comparison function that is applicable within a limited scope"

GlenD: want to add illustrative examples

<bob> the reason is A 2-adic predicate, say Ixy, asserting that its two arguments are identical. Customarily symbolized by "=" and written in infix notation, "x=y". While all systems of polyadic predicate logic can express identity as easily as any other 2-adic relation, a system is said to be "with identity" iff it also contains axioms, axiom schemata, and/or rules of inference determining how "=" is to be used. Note that an axiom like "(x)(x=x)" or "(x)Ixx" is not logic

<scribe> ACTION: Glen provides examples [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]

(assuming vote passes)

13 yes, 3 no, 1 abstain

RESOLUTION: issue 48 closed by removing section 2.3 and replacing with "Since this specification provides no concept of identity, this specifaction does not provide any mechanism to determine equality or inequality of EPRs, nor does it specify the consequences of equality or inequality. Note that it is possible to provide a comparison function that is applicable within a limited scope" and examples.

no one states that they will issue formal objection

issue i043

Any objections to closing issue 43 using proposal 1

proposal 1 is remove section comparing EPRs

RESOLUTION: issue 43 dropped with no action.

issue i026

Amended proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0190.html

vinoski: issue 24 & 26 addressed together
... creates Metadata element, moves properties into Metadata

GlenD: single address associated with multiple endpoint qnames?

Paco: WSDL provide alternatives to the one address

TomRutt: likes it that can allow proprietary policies

GlenD: what is EPR if not metadata + a couple of other things (address, etc.) ; EPR itself might be considered metadata

Chair: functional difference between metadata and rest? What is value of having data in a separate bucket?

Paco: difference between general purpose extension and metadata?

dorchard: why put in metadata & allow extensibility and if there's no functional difference, than no value add

paco: summarize: why need container as opposed to not saying anything and figuring it out

GlenD: does metadata have processing model associated with it?

Paco: it's a syntax question

vinoski: dorchard's issue is a syntax question?

dorchard: don't want it to be categorized as such
... real question is "what is its value?"
... if not see something in spec that differentiates, then no value add

vinoski: 2 optional elts in spec to begin with: interfacename, servicename - why not group them together in optional metadata section? Simplification since all optional elts combined

Jonathan: useful for human consumption; Things extending EPR, things talking about endpoint

Umit: may reuse metadata definition in other places

Dorchard: reusability never a big concern in WSDL

Marc_H: metadata bucket gives us something to hang text off in spec to talk about metadata

GlenD: WS-Policy has mustUnderstand but this metadata bucket doesn't
... if I see policy thing in bucket, can I ignore it or does it imply that I need to follow that policy?

Jonathan: the WSDL says

GlenD: then I can ignore if I don't understand

Chair: can proposers live with collapsing this to top level and getting rid of bucket?
... if it does make it into spec, can people live with that?

vinoski continues walk-through

vionoski: 2.2 example now using metadata element'

vinoski: moving service element into metadata + examples

Chair: three aspects of proposal: 1) move metadata into bucket (remove policies); 2) put WSDL-related metadata in WSDL binding doc; 3) add service

Jonathan: Problem is how to solve multi-reference problem

GlenD: do I have to include everything that was in original WSDL or can I edit it down?

Jonathan: agree that must address how to merge what's in EPR with what's in WSDL
... our biggest concern is how to reuse service element outside of context
... walks through amndment
... keep wrapper and import
... keep description wrapper and import keeps consistency
... examples show real meat
... issue - what spec does it go into (WSDL, Core)?
... issue - how imprtant is it that service and import name match WSDL

Hugo: wording in metadata pre-issue 14 dealing with cache are relevant

Chair: let's talk about it tonight and tomorrow morning and move forward

close for today

tomorrow: 9"00 in agenda for plenary

Summary of Action Items

[NEW] ACTION: Glen provides examples [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: hugo to integrate the current security text with gudge's and [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: hugo to integrate the current security text with gudge's and paco's new proposed text and split between docs and make a concrete proposal with exact text/location by tues [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: indicate that @RelationshipType defaults to [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: marc h incorpororate http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0171.html removing reference to RFC 3986 [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: marc h to add 1) to ed draft [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: marc h to change style so that type names end in Type - add "Type" to AttributedURI, AttributedQName, [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: marc h to change style so that type names end in Type [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
[NEW] ACTION: MarkN to put up schema link on wg page [recorded in http://www.w3.org/2005/02/27-ws-addr-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.115 (CVS log)
$Date: 2005/03/03 19:57:55 $