See also: IRC log
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
jmarsh fullfilled his AI on IRI, added after schema review
- 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
<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
<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
<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
<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)
Formal vote taken on closing issue i048 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. Results: 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
Any objections to closing issue 43 using proposal 1
proposal 1 is remove section comparing EPRs
RESOLUTION: issue 43 dropped with no action.
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