W3C

WS-Addressing FTF 19 April 2005

19 Apr 2005

Agenda

See also: IRC log

Attendees

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

Contents


<RebeccaB> Scribe this morning is Rebecca Bergersen; Jonathan Marsh this afternoon

Review of action items

Hugo: docs for WSDL - making progress, talking with Description WG in couple of days

Approval of minutes

Mark: approval of minutes - no objections

minutes - April 11th

Getting out of LC

Mark: scheduled end last call May 11
... May 11 also last day to register for Berlin F2F
... presentation on leaving Last Call
... number of requirements from process POV
... after last call comes candidate recommendation
... Process document outlines 10 steps
... 1 documentg all changes to document, both editorial and substantive
... editors keeping change log

Hugo - when docs generated, diff is also generated

Mark: 2 indicate if "substantive" change in doc has occured

"substantive": change that invalidates an individual's review or implementation experience

Mark: substantive change means doc needs to go back to Last Call
... we'll determine when we go to CR
... when we close an issue with a change we'll mark whether "substantive"

<hugo> Meeting: WS Addressing F2F

<hugo> Chair: Mark

<hugo> Chair: MarkN

Mark: 3 - formally addressing an issue is sending a substantive response to reviewer who opened issue
... response delegated by AI with cc to comments list
... ask for ack, further comment within 2 weeks
... record of issues and responses must be kept - Last Call Issues List
... issues considered before LC can't be reraised without new info
... reviewer doesn't have to accept. If firm objection may be reviewed by director when final review happens
... 4 - report formal objections
... objection to decision of WG, reported to director during transition

Hugo: only W3C member can make objection

Marsh: diff btwn formal objection and onjection to comment?

c/onjection/objection

Mark: formal objection sent as formal objection via email, tracked, collected on web page

Hugo: go to director with issues list. He may ask if anyone unsatisfied with our resolution and we discuss our process and consideration

Mark: want to keep formal objection and objection to our resolution separate
... will track on response whether acknowledgement, no ackknowledgement or dissatisfaction

Hugo: will do more research on who may make objection

Mark: 5 - tell whether requirements have changed
... 6 - review evidence - need to show wide review has taken place (emailfrom outside WG, external orgs, etc.
... 7 - identify features at risk
... allows hedge against features we might remove; removal of such doesn't constitute substantial change
... MUST be precisely identified; reviewers can formall object to proposed removal of features
... 8: PR Entrance requirements
... 4 implementations, not 2
... (on #7) if feature appears to put interop at risk, may go on list of risky features
... Lock period, Implementation period - how long think to implement

<hugo> re formal objections, anybody can make a formal objection: http://www.w3.org/2004/02/Process-20040205/process.html#WGArchiveMinorityViews

Mark: we can allow external implementations, by default, but we can constrain further if we want
... process requires we test every feature - empty test suite won

't do

Anish: need to make results public immediately? Mark: we'll get there

Mark: most immediately important thing will be how we address issues and how we dance the dance on responding to reviewers
... Now move into LC issues list

Last call issues list: http://www.w3.org/2002/ws/lc-issues/

lc1

Last call issues list: http://www.w3.org/2002/ws/addr/lc-issues/

Prasad: describing issue 1

Prasad: how can faults be received by sender if message id and fault endpoint reply properties not provided?

Anish - if reply-to required, how would work in one-way MEP

Glenn - do right thing if want right thing to happen

Prasad - add text to specs that props are needed if desire to handle faults

prasad: make SHOULD in text - if want to receive faults, SHOULD define properties
... In SOAP binding spec, add sentence "in order to receive these faults, message ID and fault endpoint or reply endpoint SHOULD be supplied."

Marsh - put in first couple of para section 5

Marsh - first sentence 2nd paragraph section 5

Prfasad: no objection to adding to core if desired

Mark: "in order to receive..." is conditional phrase, so this might trip up some people

<scribe> ACTION: prasad write up text handling concern with conditional properly, send to self and mail comments list [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action01]

Hugo: relation to issue 50

Mark: Use lower case should, not rfc
... lower case makes it English issue, not conformance issue

Marsh: Message ID and fault endpoint and reply endpoint properties facilitate delivery of fault back to originating party.

Mark: Message ID and fault endpoint and reply endpoint properties facilitate the delivery of faults.

Prasad: okay with text

Glenn - adds flexibility

Anish: Message ID doesn't help DELIVERY of fault, but correlates ]

Mark: Message ID and fault endpoint and reply endpoint properties facilitate the delivery and correlation of faults.
... resolution to issue 1, to be added to section 5, is "Message ID and fault endpoint and reply endpoint properties facilitate the delivery and correlation of faults."

<Marsh> ACTION: Marsh to respond to LC issue 1 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action02]

Mark: LC 2
... 20 minute break; restart ~10:50

lc2 Editorial Comments

Mark: section 2.2 example 2.1
... editorial - spelling, etc.

http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WG walks through each of the editorial problems; short discussion of changes necessary

Mark: accept all suggestions, give editorial discretion where no fix supplied
... no objections to resolution

lc3 Endpoint Reference not properly defined in section 2.2

Prasad: Many extension points described but not shown in pseudo-schema

Marsh: strike excess any in example 2-1

lc3 closed with acceptance of Marsh's recommendation

lc4 WS-Addressing restricted to XML 1.0 or not?

Prasad: confusing editorial note at end of status section "Note that this restricts use of Web Service Addressing to XML 1.0" but later state "...this is not requirement."

Marsh: note is incorrect
... remove editorial note or fix by removing sentence at end ort clarifying to restriction of :some XML features..."

resolution - no objections to removing the note.

<anish> Prasad: why do we need [source endpoint]

<anish> jonathan: [source endpoint] is kinda strange since it is not referenced anywhere else, we could change the rules or drop [source endpoint]

<anish> marc: dropping is a better solution

<anish> greg: MAPs are extensible, so one can add itin

<anish> hugo: we define MAPs, we define rules for replying, someone may come up with an interaction pattern that uses [source endpoint]. I see this as a harmless and potentiall useful

<anish> mark: it is relevant that in CR we have to test interop for features, this is a feature.

<anish> marc: this comes back to davidh's issue around MAP extensibility

<anish> greg: one adv. is that -- we can prevent DoS attack

Anish - how does it prevent DOS attacks?

Hugo: where use from in email is in rules to reply to mshg

Glenn - expand rules to cover

Umit - source enspoint can be anon EPR

Mark: substantial change if we pull source

Greg: if no implementation actiually uses it ...

Glenn: some test case may use it

Anish: what rationale for not defaulting replyto?

MarcH - substantive change

Paul: fine the way it is at moment

Mark: Prasad, acceptable if mark as feature at risk?
... no change at this point

Anish: I do see a use for the feature

Anish if use src EPR and reply EPR, you may have common proxy for whole bunch of things

Greg: if we start suggesting use, we might want to make 1st class citizen by including in rules
... is change to rules substantive?

Umit - no - just plugging hole

Anish -aligns with email pattern

Hugo - wonders if forces to return to last call

Anish: Who decides if something substantial?

Mark: ultimately hope consensus of room; if push comes to shove, we'll see.

dhull: possible no from header but src abstract property defined?

Mark: decided at earlier issue not to go there
... identify src endpoint property and places it exists and mark as feature at risk

Anish object

c/object/objects/

Mark: needs test case

Marsh: test case: malformed header and see if response comes back

Glenn: real world - auditing / logging

Mark: two proposals - identify feature at risk or modify rules

MarcH: sounds significant change - worthwhile?

Hugo: significant change is to remove source endpoint

Mark: only identify as at risk, not remove it

hugo: use case contemplated by someone may be prevented by changing semantics

Paul: leave it in as informative text

paul do as response or add something in text as "it is here'

Paul: just document it

Anish: Marking feature as something at risk tgakes away some of the functionality in use cases we had in mind

Mark: indicates WG needs more

Anish: we've heard use cases here
... so why mark as "at risk"?
... not mark as as risk - incorporate in rules

Mark: make the comment if that's what you feel

Umit: two probs Prasad wants to achieve - functionality and representation

Anish: message may be part of more complicated interaction - receiver may in future contact reply addr

Prasad: spec doesn't say anything about that

Anish: it identifies source of the message and use cases exist where that knowledge is impportant

Paul: agrees

Marsh: can set CR criteria to see some other spec out in wild that uses it.

Umit: what if my product is using it but no spec for it?

Marsh - spec or product, sure.

TRutt: poor man's multiple reply use case? Why not just a URI with some metadata?

Pauld: more info may be conveyed beyong just URI

Anish: supply proxy can use src EPR; message ID useful to receiver

Mark: is usefule to have this bucket or indulging in differing semanticvs
... 1 option - identify as feature at risk, PR to make sure external use cases, if decide later we can yank it
... 2: change defaulting rules so falls back to src EPR if reply not there; concern if substantive change
... 32: status quo - our charter to provide feature for situations; we don't need to provide rationale

c/32/3/

<abbie> can i vote

Mark: straw poll: feature at risk: 15 ; rules change 13 ; status quo 15

<pauld> chad, feeling ignored?

Mark: vote for one of three. Who has preference for feature at risk? answer: 10
... prefer chanfging rule: 9

Mark keep status quo: 6

Mark: changing defaulting rules to justify existance of source endpoint is funny

Glen: no - dependency issue

Swinkler: majority seems to agree not to put at risk

Marsh: putting at risk only holds feet to fire in terms of supplying use cases
... if not four implementations, we can remove it without problems

Anish: Do you prefer defaulting to src endpoint when reply and fault endpoints not supplied as separate issue?

Glenn: use pattern must be specified or else that way lies madness. We should specifiy what pattern does.

Marsh: can always stick in reply endpoint, so why specify default action?

dhull: can we define a use case?

discussion of optimization....

Pauld: like status quo - should just leave and move on, but marking at risk gives us process advantages, so let's mark at risk and move on.

Anish: can always specify all properties, but if not all specified and fault occurs, what do you do about it?

Glenn: when go thru LC, it's expected that comments make changes.
... minimum at end of LC, new LC can be requested
... unlikely we can get thru all issues without making "substantive changes"

trutt: have tgo put in replyto if expect reply. that goes away if we accept suggested change to this issue
... that's substantive

Mark: defer resolving issue,, let discussion occur .. look for owner of LC5 - glenn volunteers to make proposal and drive discussion

lc6 Disambiguate the Conformance statements in WS-A SOAP Binding specification

Marsh: much like issue 35
... proposes text for his proposal for statements about SOAP 1.1 and 1.2 in issue 35 be added to conformance section
... addresseth LC6 and LC35

Anish: Is there better way of saying it?
... when looking at conformance look as target - look at message, look at rules and make determination - nitpicking over the phrase
... say if follows rules then it's conformant
... if I get message without WSA header, I want to flag it as non-conformant

text being debated is: "An endpoint which conforms to this specification understands and accepts

SOAP messages containing headers in the wsa namespace targeted to it,

and generates reply or fault messages it may send in response according

to the rules outlined in this specification."

Mark: that paragraph add something new that is a change from Prasad's LC6 concern

discussion in sweveral directions simultaneously

Mark: can we choose between Marsh's and Prasad's wording?
... of first two paragraphs under conformance in LC35
... take wording to mail list and make last para topic of LC35?

<scribe> ACTION: jonatahn to start discussion of endpoint conformance on mail list [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action03]

c/jonatahn/Jonathan/

Anish: if include WSDL binding in mix, can we conclude conformance discussion?

Anish if say conform we require endpoint to emit something that can be examined WRT rules. If add WSDl binding to mix, would it make it easier to nail things down?

Anish: E.g. following rules for reply - behavior in addition to message

lc7 Typographic nits

Mark: tracking all comments, all changes

Marsh: extremely minor

Mark: missing prefix, wrong prefix, use of pseudo schema consistently, comment

daveO: yea verily

(no objections to accetance)

lc8 Rationalize URI vs. IRI

Marsh: did global search and replace of URI with IRI, but there are places where URI is appropriate
... when talk about type of field, use IRI, but when talking about string (i.e. specific instance), use URI

Hugo: may be confusing - can use IRI everywhere, since URI isa IRI
... maybe at beginning of spec, say all URIs are IRIs

Hugo - All the IRIs used in the examples are URIs

Jonathan: wants to look thru spec to see if any exceptions to Hugo's proposal

c/Jonathan/Marsh/

Mark: W3C to never use "URI" anymore?
... preference for Marsh proposal: 5
... preference for Hugo's proposal: 1
... everyone else abstaining

Hugo: web arch direction - uses IRI everywhere
... may be confusing to sometimes see IRI, sometimes URI

Mark: resolition LC8 - go with Jonathan's proposal

c/resolition/resolution/

Luch break until 1330 (now 1236)

<Marsh> Scribe: Marsh

FTF meeting schedule

Mark: We have a FTF in June in Berlin
... Next region in the rotation is East Coast in mid-late July.
... Then there's the question of whether to take a holiday in August.
... Who will not be available for a substantial portion of August?

(7-8)

scribe: My expectation would be that we'd have a FTF in early Sept. to get us back on track.
... That meeting will be here in the Bay Area.
... Theoretically the meeting after that would be overseas. (Late Oct?)
... Looking for volunteers to host these meetings.
... Decide on August holiday at Berlin meeting.
... Only reason we wouldn't take a holiday is if we're at a critical time in our schedule.

Bob: Informal poll on willingness of WG to meet in Japan?

Mark: Location is chair's decision, Japan is something we'd like to do, I'll be looking at Japan late this year or early next year.
... Have some other offers to host in London and Sri Lanka.

LC9

http://www.w3.org/2002/ws/addr/lc-issues/#lc9

Marsh: (introduces the issue)

TonyR: messageID absolute?

DaveH: Discussed this already.

RESOLUTION: Accepted Jonathan's proposal.

<scribe> ACTION: Greg to respond to LC9 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action04]

LC10

http://www.w3.org/2002/ws/addr/lc-issues/#lc10

Marsh: (introduces issue)

Anish: Implication that ref params have to have a namespace?

Marsh: Think that's what this text is trying to do.

RESOLUTION: Accepted Jonathan's proposal.

<scribe> ACTION: Tony to respond to LC10 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action05]

LC11

http://www.w3.org/2002/ws/addr/lc-issues/#lc11

Mark: (introduces issue)

Anish: I have a related issue, haven't sent it.

Mark: Please send to the list.

RESOLUTION: Accepted Jonathan's proposal

<scribe> ACTION: Paul to respond to LC11 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action06]

Topic LC12

http://www.w3.org/2002/ws/addr/lc-issues/#lc12

Mark: (introduces the issue)
... Does anyone know what was intended here>?

Glen: Seems to be about whether they appear as XML, HTTP headers, etc.

Marc: Not so much the "use of". More about serialization or encoding...

DaveH: Reification...

Marc: Amendment: Change "use" to "serialization".
... SOAP would be the protocol here...

RESOLUTION: Accepted Jonathan's proposal as amended by changing "use" to "serialization."

<scribe> ACTION: Marc to respond to LC12 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action07]

LC13

http://www.w3.org/2002/ws/addr/lc-issues/#lc12

Marsh: word "each" no longer refers to something specific.

Hugo: EPR comparison was removed.

RESOLUTION: Accepted Jonathan's proposal.

<scribe> ACTION: DaveO to respond to LC13 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action08]

LC14

http://www.w3.org/2002/ws/addr/lc-issues/#lc14

RESOLUTION: Accepted Jonathan's proposal.

<scribe> ACTION: Vikes to respond to LC14 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action09]

LC15

http://www.w3.org/2002/ws/addr/lc-issues/#lc15

Glen: What if I send a message that is a combination of three. Can I resply to all of them?

DaveH: Don't want to preclude something if we don't know it's harmful.
... There may be more than is dictated by the requirements of the MEP.

Glen: Not particularly about a specific MEP.
... Possible to indicate a set of messages.

DaveH: Underlying semantics are hazy. Maybe a bug, maybe a feature.
... In request-reply there is a single reply message.
... In a different MEP there might be a different relation.
... Not so harmful to exclude for request-reply.

Glen: We could say the same thing about ReplyTo.
... You're defining the MEP in a subtle way.

Anish: You're thinking app-level response to multiple messages? ('ack')

Glen: You're going to have to understand these messages in the context...

Anish: We already limit [reply endpoint] to maxOccurs 1.

Glen: Two ways to go: 1) crisp things up, but doesn't go far enough. 2) loosen it up, say "must contain appropriate relationship properties."

DaveH: This proposal moves further towards crisp.

Glen: I'd like to see ReplyTo defined in terms of request response, not reused elsewhere.

Nilo: Use case is bulk acknowledgement.
... We call it acknowledgement at a high-level, at the WSA level it's reply.

Glen: What's being teased out is that there is some delicate semantics implied by "reply message".
... Either we should be clearer about what those mean or we should remain abstract.
... reformulate as: "A message must contain zero or one relationship properties with the URI ...reply."

Mark: 'A message MUST NOT contatin more than one "reply" [relationship]'

Nilo: What if I formatted some data as several messages. How do I indicate a bulk ack?
... best to invent a new URI for that purpose.

DaveH: Now we've taken a little bit more of the WSDL req-resp MEP into the Core.

Marsh: We've changed the text but lost the requirement to have one.

Hugo: What is broken if we leave it as is?
... The reply rules say you put in one.

Glen: When parties are communicating, they have in mind the pattern that's engaged. If I send you a message, and you respond with a relationship on it, we agree what that means.
... I'd like things to be crisp, we need to have a way to describe the contract implied by the relationships. You can introduce new headers for slightly different semantics.
... Not hard to introduce new headers.

Hugo: We should then clarify that this is a reply with in a request-response pattern.

Anish: The idea of reply is in the description of the URI itself, yet we're not defining "reply". Seems like we should move this to the WSDL binding.

Umit: There is an agreement, but not all exchanges need to be in WSDL. Two one-ways might constitute a request reply.
... Doesn't have anything to do with WSDL binding.

Glen: One meaning is request-reply. Another is a conversation, with request, reply, repliy, reply, ... end.
... Any kind of lockstep conversation. Should we have a different URI for that?

Anish: Up to you to define those URIs, why do we need that in the core?

Glen: We need some concept of a MEP somewhere (WSDL or elsewhere).

Umit: basic building block, don't take it out of the core.
... I'm in line with crisply defining that reply can only occur once.

Anish: If we try to define what reply means in absence of WSDL MEP it becomes hazy.

Glen: Use english.

Anish: Why would we constrain it as Jonathan proposes?

Umit: Describes when reply needs to occur.

Glen: When you do reply, it's only to one.

Nilo: Is the important thing the fact that it relates to, or the semantics of how it relates?
... Leave the relationship type to some higher level.

Glen: What
... 's the utility of defining the relationship without the patterns?

DaveH: Are these properties defined in relationship to their WSDL MEP meanings or are we abstracting out a notion of reply? We don't say which we're trying to do.
... If I see "Core" I'm expecting seeing addressing in general. We've been bringing in more and more of the WSDL MEPs.
... If we do say it's bringing in the WSDL MEPs, we should quarantine it to the WSDL Binding.

Glen: There is a more general concept, in WSDL and in SOAP, of a message exchange pattern.
... If we were able to pull that into a realm where we could talk about it.

DaveH: We can talk about MEPs that don't have concepts of reply or fault.
... Let's say what we're doing.

Mark: Should we accept this proposal while we're investigating these larger issues?

Nilo: A message sent as a reply to another must contain exactly one [relationship] property consisting of the predefined reply URI and the message ID of the original message.
... A message sent as a reply to another must contain exactly one [relationship] property consisting of the predefined reply URI and the message ID of the original message.

Anish: Same ambiguity as the first; constraint apply to the pair or to the relationship?

<scribe> New proposal: Keep the original text ('a relationship property'). Add "A message MUST NOT contain more than one 'reply' [relationship].

A reply message MUST contain a [relationship] property containing the predefined reply URI and the [message ID] property of the request message. A message MUST NOT contain more than one [relationship] containing the predefined reply URI.

RESOLUTION: LC15 closed: "A reply message MUST contain a [relationship] property containing the predefined reply URI and the [message ID] property of the request message. A message MUST NOT contain more than one [relationship] containing the predefined reply URI."

<scribe> ACTION: Hugo to respond to LC15. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action10]

LC16

http://www.w3.org/2002/ws/addr/lc-issues/#lc16

Marc: Alternate proposal: delete the paragraph.

Also see LC54.

Mark: Any objections to dropping it?

Umit: Like keeping this, as rationale for the design.

Marc: We can drop because we already say what these properties are for, dispatching is none of our business.

Umit: We've had a lot of discussion in WSDL about dispatch, like to see some rationale here.

Mark: What if we change "facilitate" to "may facilitate"?

Glen: Why do we need to say "dispatch"?
... The important part is what you send, not how you process what you recieve.

Marc: Kinda lame.

RESOLUTION: LC16 closed with Jonathan's proposal, amended by "may facilitate".
... LC54 also closed with LC16 resolution.

<scribe> ACTION: Nilo to respond to LC16, LC54. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action11]

20 min break

--resuming--

LC17

http://www.w3.org/2002/ws/addr/lc-issues/#lc17

Marc: The previous section talks about NAT and stuff, it seems like this is still talking about replies of some description. Are we prohibiting the use of anonymous in the To?

Tom: anonymous is the default for wsa:To, implies it's allowed.

Marc: Might need to do some work on the preceding sentence as well.

Vikas: The word anonymous means what in relation to NAT and DHCP, which are not anonymous.

Greg: The true address is not visible. It's unknown outside the NAT.

DaveH: Two things going on: it is the backchannel, and it's also anything you can't name. We need to nail down the intent.

Marc: Does it mean backchannel?
... or use some underlying protocol.

Marsh: Specific to the underlying protocol.

DaveH: Means "you know what to do with it" Seems like some interop issues there.

Glen: Because I'm using request reply, I'm saying get it back to me.

DaveH: Think the semantics aren't very well defined.
... Perhaps define a backchannel URI to mean backchannel.

Mark: Seems like an issue on the preceding text. Please raise an issue if you want.
... Ok with the resolution to this issue?

Marc: change to say "To allow these anonymous endpoints to send and receive messages..."

Marsh: OK by me.

RESOLUTION: Accept Jonathan's proposal for LC17.

<scribe> ACTION: Anders to respond to LC17. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action12]

LC18

http://www.w3.org/2002/ws/addr/lc-issues/#lc18

RESOLUTION: Accept Jonathan's proposal for LC18

<scribe> ACTION: Rebecca to respond to LC18 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action13]

LC19

http://www.w3.org/2002/ws/addr/lc-issues/#lc19

Anish: WebArch problems with simple string compare?

Marsh: Probably not - XML namespaces work like this.

RESOLUTION: Accept Jonathan's proposal for LC19

<scribe> ACTION: Anish to respond to LC19 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action14]

LC20

http://www.w3.org/2002/ws/addr/lc20

http://www.w3.org/2002/ws/addr/lc-issues/#lc20

Glen: Likes the first part, not the second.

DaveH: Distinguish backchannel from other semantics.
... Some transports have backchannels, others don't. There might be more that needs to be captured from the protocol.
... If your transport defines this, it should define it as a sensible place to put replyTo and faults.
... In the case of HTTP the backchannel is the sensible place for replies.

Tom: What does is mean to put it in the destination?>

DaveH: Assume it means send the message up the backchannel.

Glen: Unless you aren't in a situation with a reasonable binding, in which case you barf.
... We all know what we want to happen.

Marc: Seems like an echo on the logical vs. physical which we never really closed on satisfactorily.

Glen: Continue to dance around the MEP issues.

DaveH: Considerably more tangible than log/phys.

Marc: Only because you're tying to backchannel responses. anonymous is fine for one-way if we delegate to the binding.

Glen: In a particular case it means a particular thing doesn't preclude other cases.
... You don't even need a To in some cases.

DaveH: There are some transports that define a backchannel, we want to say use the backchannel.

Glen: Can generalize more: some transports can do more. What if I have a binding that is a single "wire".

DaveH: Can we say "anonymous" with a replyto or faultto means the backchannel - an error if there isn't a backchannel.

<umit2> This reminds me of what was in Message Delivery. Here is what was the description:

<umit2> A special URI value " http://www.w3.org/2004/04/ws-messagedelivery/destination/transport-specified" MAY be used to indicate destinations that either do not have a WSDL service description (such as Web service clients) or destinations that do not have a dereferenceable endpoint. The underlying transport mechanisms, such as HTTP connections, may be used to distinguish such destinations.

Marc: For SOAP/HTTP for a request sent in an HTTP entity body, anonymous means the backchannle.

Glen: There is a call for a middle ground that isn't HTTP-specific so you don't have to rewrite this thing over and over again.

DaveH: Backchannels are an important fact of life. (BEEP, JMS). We want to capture it and give it it's own name.
... We shouldn't use the same name for non-backchannel use.

Tony: Should be "binding in use" instead of "transport in use"?

(yes)

Tom: Gudge said "you know what to do with it"

DaveH: dangerous

Glen: Is there a way to more crisply define what that means?

DaveH: I have app logic that I want to get my reply directly back. I'd like to pass that to the infrastructure and have it do the right thing.
... If the infrastructure doesn't know what that means, I get breakage. Things can move under your feet.

Marc: I'm with you if "backchannel" was "connection". You might want to use "connection" for subsequent messages in a conversation.
... Destination would be anonymous, replies to that message would be anonymous.

Umit: "transport-specified"

DaveH: In HTTP you know what it means, in other bindings you might not.
... If I don't know the binding in advance I can't use the value safely.

Glen: At the app level, yes. Which layer is sticking this message into the envelope? A lot of frameworks may do this work for you.

DaveH: There's a monster behind the door.

Hugo: The spec says the use of anonymous no claim was being made. Could we say it's the "no claim" URI?

<GlenD> http://smollin.com/book/mikes/tmonstr/mon001.html

Hugo: We talk about the behavior being unconstrained in this spec (in the rules). Can we reuse text like this for anonymous URI?

<umit2> Tobe clear, I was not suggesting changing the uri to transport-specified to anonymous. Suggestion is to use the last statement as I quoted from message delivery

<dhull> I don't think that changes much either way

Umit: Do we like the first part of the proposal?

DaveH: I don't

Tony: It's appropriate to say "go look in the binding'

DaveH: We don't define any semantics in the core.

Glen: We either say what it means at a high abstract level, and allow it to be clarified at the binding level.
... Or we don't define it at all.

(discussion leaks a bit...)

Mark: Take it to the list.

LC21

http://www.w3.org/2002/ws/addr/lc-issues/#lc21

Marc: +1

<RebeccaB> +1

Mark: Step forward on the discussion we just had.

RESOLUTION: Accept Jonathan's proposal for LC21.

<scribe> ACTION: Arun to respond on LC21 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action15]

LC22

http://www.w3.org/2002/ws/addr/lc-issues/#lc22

<RebeccaB> +1 on proposal for lc22

Glen: I could use another header with mU to override this if I needed to.

RESOLUTION: Accept Jonathan's proposal for LC22

<scribe> ACTION: Tom to respond on LC22 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action16]

LC23

http://www.w3.org/2002/ws/addr/lc-issues/#lc23

Mark: Continuation of URI/IRI for SOAP doc.

RESOLUTION: Accept Jonathan's proposal for LC23

<scribe> ACTION: Bob to respond on LC23 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action17]

LC24

http://www.w3.org/2002/ws/addr/lc-issues/#lc24

RESOLUTION: Accept Jonathan's proposal for LC24

<scribe> ACTION: DaveH to respond on LC24 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action18]

LC25

http://www.w3.org/2002/ws/addr/lc-issues/#lc25

Anish: Does it make sense to have things in the same namespace for versioning purposes.
... Different namespaces and schemas would help versioning (independent of how many specs)

DaveO: Leaning towards doing it.

Rebecca: Might open up new problems. E.g. Anish's versioning problem, making it more difficult to avoid the implication that this is SOAP-specific.

Marc: I wonder if we should improve the separation by putting the XML representation in the SOAP binding.

Paul: Abstracting from XML even.
... How do you apply the XML infoset to MQSeries?

Rebecca: Positioning problem.

DaveO: Majority case is SOAP, let's make it simple.

Mark: In the extreme we'd separate abstract, XML, and SOAP. But I'm reminded of RFC2045 which buried in media types.
... In the end we had to pull that out so we could reference it in other contexts.

Marc: We could separate the abstract from the SOAP infoset. That would make it clearer by moving some of the XML infoset stuff to the SOAP binding.

Anish: Isn't the XML representation useful to more than SOAP?

Marc: Knock yourself out.

Mark: Thinks it's OK to have a single doc per our charter.

Marc: Prefers two docs.
... Would like to move the XML representation to the SOAP spec.

Mark: Strawpoll:

Option 1: Maintain the current split: 11

Option 2: Zip together: 3

Abstain: 7

RESOLUTION: LC25 closed with no change

<scribe> ACTION: Prasad to respond on LC25 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action19]

LC26

http://www.w3.org/2002/ws/addr/lc-issues/#lc26

Hugo: Would this align with SOAP 1.1?
... Action is not aligned (SHOULD vs. MUST) so we need to do it differently in SOAP 1.1.

<scribe> ACTION: Marsh to look into the impacts on SOAP 1.1. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action20]

LC27

http://www.w3.org/2002/ws/addr/lc-issues/#lc27

<hugo> Discussion about action alignment: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0210.html

Marsh: pendantic

Glen: Could say "Each property that is of type IRI MUST be serialized as an absolute IRI in the SOAP header for that Message Addressing Property."
... Could say "Each property that is of type IRI MUST be serialized as an absolute IRI in the corresponding SOAP header representation for that Message Addressing Property."

RESOLUTION: Accept Jonathan's proposal for LC27, as amended by Glen.

<scribe> ACTION: Glen to respond on LC27 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action21]

LC29

<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc29

RESOLUTION: Accept Jonathan's proposal for LC29

<Marsh> ACTION: Pete to respond on LC29 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action01]

LC30

<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc30

Marc: IsReferenceParameter is SOAP-specific. We should define it there.

Marsh: Putting the definition in the Core is not central to the proposal. We could put it somewhere in the SOAP spec instead.

RESOLUTION: Accept Jonathan's proposal for LC30, amended by putting the definition in the SOAP spec somewhere instead of in the Core.

<Marsh> ACTION: Umit to respond on LC30 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action02]

LC31

Glen: We could fix on the presence instead of the value.

<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc31

RESOLUTION: Accept Jonathan's proposal for LC31

<Marsh> ACTION: Steve to respond on LC31 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action03]

<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc32

Glen: Is there any other SOAP-specific markup that might be added?

Marc: Any other soap markup will already be there.

RESOLUTION: Accept Jonathan's proposal for LC32

<Marsh> ACTION: Jeff to respond on LC32 [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action04]

LC34

<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc34

Marc: Is there a problem when a node plays multiple roles?

<Marsh> ... We're making something illegal but there's a way to get around it.

Marc: If you write the text from the POV of the reciever, if you get more than one header targetted to you you fault.

Glen: SOAP says you union the roles you play and then iterate over those.

DaveH: What does it mean for an intermediary to have a ReplyTo?

Marc: Amendment: change "ultimate reciever" to "recipient".

<Marsh> ... "targetted to the same role"

Greg: Do you have to distinguish "next" and "ultimate reciever"?

Glen: We do intinerary-based routing, and like to be able to target sets at different nodes along a path.

Marc: Each node gets one MAP.

Glen: Don't know beforehand what distinguishes A and B.

Marc: If we don't preclude it we have to specify what happens.

DaveH: Where do we talk about this?

Marsh: SOAP section 3.3 after the bullet list is where I propose this goes.

Mark: Choose between "node" and "role".

Greg: Why not change "ultimate reciever" to "node"?

Glen: Precludes smart processing of multiple roles by a node.

Marsh: Can an entity act as if it were two nodes?

Glen: Yes...

DaveH: Can we define a new fault for this?

Glen: Nice to have another fault for this case - an intermediary might add the duplicate header.

Marc: reword without MUST - it's not a testable assertion.

<Marsh> ACTION: Marsh to rework proposal, adding a DuplicateProperty fault. [recorded in http://www.w3.org/2005/04/19-ws-addr-minutes.html#action05]

Mark: Get your issues in.

<Marsh> ... We'll start again at 9AM.

 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.122 (CVS log)
$Date: 2005/04/23 01:52:41 $