W3C

Web Services Addressing Face-to-Face

18 Jul 2005

Agenda

See also: IRC log

Attendees

Present
Rebecca Bergersen (IONA Technologies, Inc.)
Andreas Bjärlestam (ERICSSON)
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.)
Yin-Leng Husband (HP)
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)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (Computer Associates)
Katy Warr (IBM Corporation)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp (SAP AG)
Prasad Yendluri (webMethods, Inc.)
Absent
Abbie Barbir (Nortel Networks)
Ugo Corda (SeeBeyond Technology Corporation)
Dave Chappell (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Jacques Durand (Fujitsu Limited)
Yaron Goland (BEA Systems, Inc.)
Marc Goodner (Microsoft Corporation)
Martin Gudgin (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Amelia Lewis (TIBCO Software, Inc.)
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
Tony Rogers, Steve Winkler

Contents


AOB

Discussing process of handling formal objections

JeffM: protesting the method of handling the formal objection as an abuse of process

Glen: will want some time to discuss the Async TF results

Chair: other Administrivia

Chair: want to take a break in August

Chair: note that one organisation has three representatives on the WG

Chair: MS has added a third participant (Mark Goodner)

Chair: note that the charter does not restrict the number of participants

Chair: note that this does allow organisations to bring their QA people into play to assist with the CR process

Chair: keeping an eye on the issues relating to good standing rules and the question of weighting straw polls

Chair: if necessary, will move straw polls to one/organisation

Marsh: reason for including an extra person - Gudge may be moving on, and Marsh may have trouble attending. We want to make sure we maintain active participation.

Glen: possible to use the "invited expert" means of involving others
... may want to do this to involve someone from Apache

future face-to-face meetings

Chair: looks like best week will be week of September 26th

Omnes: rumblings of date clashes

Chair: still looking for a host

Looking rather urgently for a host in the Bay Area

scribe: Tentative dates are 27th and 28th - hope to settle this this week

Next F2F after this would be November - week of the 7th or 14th

scribe: Week of the 14th looks problematic - consider the week of the 7th.

Week of November 7th - any problems?

Next one after that would be January - week of the 9th or 16th

And after that is W3C Tech Plenary - end Feb / start of March - pretty much set in stone - in Nice

January will probably be US east coast

November is likely to be overseas

Possibilities for November are: Tokyo, Sweden, and London.

Omnes: Tokyo looks good!

Chair: looks like the week of November 7th in Tokyo

Bob: Hitachi is willing to provide facilities for WSDL as well as WS-Addr

Chair: looking for a host for January - probably week of 9th of US East Coast

Chair: willing to consider mid-US

minutes of last meeting

Chair: defer consideration to tomorrow

Action Items

Chair: done

LC69 - revisiting

Chair: response from originator to closure with no action - suggesting changes to language

Jacek's suggestion is accepted

<scribe> ACTION: Mike to respond to Jacek [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action01]

LC76

DaveH: providing a standard means / language for returning a fault - not mandating format, but suggesting things that could be included in the detail element
... Proposal suggests content to include with any of the four "standard" faults
... Attach language to the binding in Section 7
... Minor issue with mechanical details of how to include this.
... main objective is to make faults more useful / informative

mixed discussion of origin of faults, content

<Zakim> Marsh, you wanted to ask about MismatchedAction content

PaulD: if we mandate these we must test for them. Fair enough to have them as suggestions, but not mandatory

DaveH: not mandated - just suggestions - if you want to include this information, this is standard way to do it. SHOULD not MUST
... there are occasions when one may wish to omit the detail (eg: list of supported actions), hence the SHOULD
... most of this goes in the InvalidAddressingHeader - added after the QName that is the standard content of that header
... will probably need to wrap the QName

SteveW: is this an exhaustive list?

DaveH: fine to add some language which indicates that this is not exhaustive

PaulD: concerned about putting this into the Core - perhaps it should be published as a Note or Adjunct

DaveH: Perhaps

<Zakim> Marsh, you wanted to ask whether we expect interop on the difference between malformed IRI and relative IRI.

<pauld> sees this as a bi-product of writing a test assertions document

Umit: in favour of this proposal - good to have standard error information format

<Marsh> +1 to a bit over the top!

Marc: concerned that this is a bit too detailed

Discussion of testing and the need to test all of the error conditions

PaulD: may need to add error codes as we develop the tests

Umit: interop depends on standard descriptions of faults / error content

Steve: yes, never finish with errors, but having well-defined errors is helpful
... we can add more errors in an extra document, but let's include the ones we know now

PaulD: does this mean we have two lists of errors?

TonyR: but it is not the list of faults we're discussing - the faults are agreed - we are talking about the detail

DaveH: have never seen an error message that was TOO detailed... Concerned that this isn't fully baked yet

Chair: can we change a list of errors during CR without kicking back to LC?

Hugo: probably not count as a substantive change
... unlikely to violate the rule about "affecting some-one's implementation or review experience"

<yinleng> abstain

<mlpeel> abstain

Straw poll: 11 in favour, 3 against, 3 abstain

PaulD: likely to change, shouldn't be in the spec

Marc: it's overkill

TonyR: asking those against: OK to include faults, but not the detail?

Marc: yes

PaulD: yes

Chair: can we get the proposal "baked" to increase it's acceptability?

<pauld> seems like accepting this will prevent us being able to vote on leaving CR tomorrow. Expensive "wouldn't it be nice if ..." :-(

Marsh: prefer to not get this in rather than waste lots of time on it
... question on detail of one fault

<pauld> s/one fault/detecting the difference between relative and malformed IRI/.

Omnes: perhaps we should drop the "non-absolute IRI" fault - treat it as a malformed IRI
... include the non-relative information as a detail information

Marc: should we have a subcode for SOAP 1.2?

DaveH: good idea - perhaps we should use subcodes for several

Marc: we already describe detail content for some of the faults - relationship of the existing content to these new contents?

DaveH: discussing particular cases

Marc: make the new content siblings to the existing content?
... the text is rather generic at the moment - we would need to be more specific. This is a reason why this proposal seems "inadequately baked".

DaveH: that's why I'd prefer to make this an appendix

Chair: appendix or separate document? Appendix must be included when going to CR; separate document can be published any time

Chair: does moving the details to appendix / sep document affect CR?

Marc: can have multiple detail elements - perhaps leave current detail content in first detail element, include this new stuff in extra detail elements?

Omnes: discussion of separate document vs including in spec; discussion of process
... discussing mechanism for including this into the spec

Chair: need a volunteer to lead a short-lived group to design this proposal - preferably someone other than DaveH - coordinate with Marc to ensure inclusion of his ideas

Omnes: guilty shuffling

Chair: we'll convene some people at lunch to attack this problem.

Marsh: perhaps we can build some of the differences between Faults into the names of the properties, and make things more generic

DaveH: that makes sense

Marc: we have some of that already

Umit: can be issues with using sibling elements

DaveH: nervous about including this stuff right now because it needs refinement

<Zakim> Marsh, you wanted to ask about @property

Chair: we'll meet at lunch and discuss tomorrow.

<uyalcina> I would prefer child elements since the parent contains info about the property already

Chair: break now - back at 11am - will move on to LC20

Chair: break REALLY now

Restarting

LC20

Chair: originally raised by Jonathan - clarifying the semantics of the anonymous URI

Proposal by DaveH

<mnot> http://www.w3.org/mid/42D8778C.9040402@tibco.com

DaveH: introducing the proposal
... a selection of symbolic URIs - starting with anonymous vs sender

<Zakim> Marsh, you wanted to note this proposal has little relation to the original comment.

Marsh: this does not address the original issue, indeed, it seems this was deliberately NOT the intent

DaveH: thought the complaint was that anonymous was too vague; introduced sender to address the sending of a message down the back-channel (if any)

Chair: would it be acceptable to say this is addressed by the binding? Push it to the binding document?

Marsh: would be happier to close with no action

DaveH: but then we have no hook to hang the back-channel on
... better to have sender to use for this

Glen: could make this a feature of the underlying binding - HTTP supports this feature

DaveH: but "sender" can go further

Paco: the core can specify that the meaning of anonymous is specified by the binding

<Marsh> +1 to Paco - not gaining much.

DaveH: but anonymous can be different from sender, defined by binding

Chair: do more people feel that anonymous should be stated in the core as meaning defined by the binding

DaveH: problem - anonymous being defined by the binding could change the meaning of an address when moving from one binding to another

Umit: discussing difference between anonymous meaning "deferred to another spec" and meaning "out-of-band"

DaveH: but anonymous is used for "out-of-band" today

Discussion of current meaning / possible meaning of anonymous

Lots of discussion of value of "sender"

Anish: wondering if we should remove the anonymous URI altogether from the core spec, and defer it to the SOAP spec

<Nilo> I'd like two

<prasad> +1 to two

Straw poll: Do we need one URI, two URIs? One: 7ish, Two: 5, Abstain: 4ish!

SteveW: should we define just one URI, but allow the definition of more at a later time?

<steve_winkler> ala our wsa:RelationshipType...

discussion on meaning of anonymous once we have a new "sender"

Chair: if we do have sender, should ReplyTo / FaultTo default to sender

Omnes: Yes

Anish: if we move this to HTTP, and say what it means, what do we lose?

Marc: we lose ability to default in the core - must move infoset to the SOAP binding

Paco: so we only care about the SOAP / HTTP case? What about SOAP / TCP?
... we must define this again in each binding document?

Anish: yes
... they are free to define what this means in their case

Umit: the anonymous URI is a forward pointer - must look at the binding document to determine meaning

SteveW: we should point out that we support multiple IRIs explicitly

MNot: always thought that was implicit

JeffM: if we go down this path we must ensure we define the IRI in all the bindings we define

Marc: we can define anonymous in core / specify its meaning in binding

Chair: we define one or more URIs in the core, defer semantics to the binding (except for "none" - defined in the core)

Omnes: yes

Anish: per underlying transport binding we have a meaning of the IRIs
... can we have just one, and call it "sender"?

TonyR: No, because sometimes we want to send the request to "anonymous" - that's not the same as "sender"

<anish> +1 to one anon URI

<RebeccaB> Another +1 to one anon URI

Discussion of whether sender is useful / required / desirable

TonyR: can we specify in the core that an underlying transport binding must define the Anonymous IRI?

Anish: cannot require the binding to define the anonymous IRI, because the binding may not permit the use of anonymous - perhaps "the underlying protocol binding must specify the semantics of the anonymous IRI"

circling discussion - difficult to capture

TonyR: how do we distinguish symbolic IRIs from real addresses?

Chair: you require an enumerated list of the symbolic ones

SteveW: how do we define something like a special IRI for the use case Glen suggested (determine the address from the digital signature) - do we give it a new symbolic name?

Paco: anonymous can cover that

Anish: if that travels over HTTP, how do we distinguish these cases?

<steve_winkler> Slgiht correction: there are two semantics overloaded with current definition of anonymous: out of band and transport specific. Defining a URI for each and making the text more crisp, while illustrating that more URIs could be added, might be a better way to go.

General discussion reaching almost consensus on returning to Jonathan's proposal

<Nilo> The IETF makes everything URNs

Chair: so we need a volunteer to capture a proposal for this

<Nilo> That was just FYI

Glen volunteers

<scribe> ACTION: Glen to present a new version of the proposal for LC20 this afternoon [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action02]

Lunch break to 1:30 US EDT, may extend depending on progress of subgroups

<mnot> Lunch extended for 15 minutes (possibly more)

<GlenD> When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

<steve_winkler> Scribe: steve_winkler

lc20 continued

Glen: describes above proposal.

Paco: you're defining the foo URI in the core in the binding?

Glen: No, this means the semantics are defined by the underlying transport.

Paco: That wasn't my understanding of what we were going to do.
... I think it was clear that we didn't agree on the sender part.

Mark: we kind of came to a place where it was protocol specific.

Paco: It may be transport specific, but it doesn't make the connection that the URI isn't stable/resolvable which is what we have today.

Glen: We could make back channel more specific, by saying that it delivers the reply message to the sender.

Mark: I thought we wanted to be able to use this not only in the ReplyTo but also in the To as a default.

<GlenD> When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

Marc: If that URI is in the reply message, does that mean that you have to provide a back channel for a reply message (reply to a reply)?

Glen: Yeah, you have to deal with that anyway.
... One option is to say, don't do that.

Marc: It could just be a DWR (Do What's Right).

Glen: That's hard for interop.

Marc: Just act if it wasn't there. Do what you do anyway.

Glen: That sounds fine if we can say that somehow.

Anish: Aren't we getting into trouble by not defining the context. We define the meaning, but not depenedent on where the URI is found.

Glen and Paco go back and forth. Anish adds his 2 cents...

<bob> more like to and fro

Paco: We are trying to give a provisional name for something that doesn't have a name.

Anish: I tend to agree, but we are also saying something specific when it's used in ReplyTo
... It seems that we're trying to define it in a more general way.
... In the soap binding all we need to talk to is what is done when this URI appears in the ReplyTo.
... If the same URI appears in To, the SOAP binding has nothing to say about it.

Glen: Because it's the guy on the other end of the binding.

Paco: you can't make it relative. It's absolute within the context of an exchange.

Mark: 3 proposals
... 1 = act as if addressing wasn't here
... 2 = Transport-specific; 'to the unnamed'

<mnot> When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

Mark: 3 = Transport-specific; 'use the back channel'

Anish: 4 = Combination of 2 and 3.

Glen: Any of these MAPs, they only become interesting in the context of an MEP.

<dorchard> I propose changing "transport" to underlying protocol.

Paco: We want to keep the part about the endpoints for which you can't assign a URI.

Anish: Weren't we going to remove the part about NAT, DHCP, etc?

general nods of agreement by the group.

Glen: This text isn't so bad, it just doesn't say what to do in Req-resp over HTTP.
... We just need to capture that somewhere.

Anish: Why can't we just say that in the SOAP binding?

Glen: Am I allowed to send it somewhere other than up the http resp when anon is in the replyto?

Anish: No. You have to send it back on the back channel.

Glen reads to himself out loud.

<bob> And the binding said unto the transport I AM THAT I AM: and it said, Thus shalt thou say unto the children of thy message I AM hath sent me unto you.

Mark: Would we put that in the core or the soap binding?
... Do we need something for the to?

Marc: If we do that, we'll need to talk about whether it's an HTTP Req or an HTTP Resp.

Umit: We need to say something in the SOAP binding that relates it back to the anon URI that is defined in the core.

group wordsmithing ensues.

<mnot> Core: http://www.w3.org/@@@@/@@/addressing/context-specific

<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the context of use; e.g., in a binding of Addressing to a specific protocol.

<mnot> SOAP Binding:

<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

<Marsh> @@URI@@ is .../context-specific?

Paco: It should still be 'anonymous' and not context specific.

<Marsh> +1 to anonymous

Anish: Why do we use 'context' instead of transport binding?

Marc: Why can't we say in a protocol to which WS-A is bound?

<prasad> +1 to anonymous; BTW, where is this text going in the spec?

<mnot> Core Table 2-1: http://www.w3.org/@@@@/@@/addressing/anonymous

<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.

<mnot> SOAP Binding:

<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

Rebecca: what is the optionality on the word 'provides'?

Glen: In the first sentence, MUST is ok, in the second, it's ok.

DaveO: When it says any underlying protocol that supports SOAP req/resp MEP, this could cause problems...(sorry dave, couldn't quite catch)
... It doesn't work to use anonymous in that case.

Anish: If you're using WSA to enable that, you'll never use it anyway.

DaveO: That's my point.

Glen: You have to separate your concerns.
... If you try to overload it, it's inappropriate.
... If you want to do something else, that's fine, because it correctly layers under the SOAP MEP.

Anish: If you did overload, your binding would prevent you from doing anonymous.

DaveO: What's the point of the second sentence?

Glen: We're trying to resolve LC20, it's never specified how to send a response for http on the back channel.
... This tells you that the reply message is going to go in the response because of the req/resp MEP.
... For Req/Resp MEP, there exists a back channel for every binding.

<mnot> Core Table 2-1:

<mnot> http://www.w3.org/@@@@/@@/addressing/anonymous

<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.

<mnot> SOAP Binding:

<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

Glen: At least this way, we cover all transport bindings...

Umit: One of my concerns is that we have covered SOAP 1.1 and 1.2, and I don't like that to be explicitly called out.

<dorchard> I wonder about the use of the word "channel". I'm thinking of Umit's "two connection" binding, and whether another http connection is a "channel"

<prasad> Does the binding need to "define" the precise meaning of the URI?

DaveH: If you're doing req/resp and you switch transports, you're still probably ok.

Mark: Can I get a show of hands as to who cares about this distinction.
... result = 3 people. Let's resolve this quickly.

Umit: I just didn't want to tilt it towards SOAP 1.2. With 1.1 there is no definition of MEP.

Glen: describes some crazy cars versus bike transportation analogy.

Mark: straw poll. A, B, don't care.

<dorchard> I don't see umit b

<mnot> Core Table 2-1:

<mnot> http://www.w3.org/@@@@/@@/addressing/anonymous

<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.

<mnot> SOAP Binding A:

<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

<mnot> SOAP Binding B:

<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

<yinleng> don't care

A - 6

B - 1

<mlpeel> don't care

<dorchard> upon reflection, glen is right about A.. It does work for the 2 connection binding

<Marsh> don't care

<GlenD> ...as long as the binding correctly implements the req/resp machinery itself

C - 13

Mark: final thoughts? Does anyone object to this as a resolution?

RESOLUTION: Option A is accepted as resolution to LC20.

Jonathan is on the phone and doesn't object.

Anyone object to closing I50 (replyTo, FaultTo issue), we needed to reopen that to close LC issues.

Group affirms that I50 is closed.

RESOLUTION: I50 is closed for the same reason that the related LC issues were closed.

LC87 and LC55

<mnot> http://www.w3.org/mid/012FE7D1-0024-4F98-8849-50ACDE73E524@Sun.COM

Marc: Fixed editorial topics from Hugo. Also put in two versions of the establishing EPR trust.
... Main controversey is whether we should specify normatively how people should determine the trustworthiness of an EPR.
... If we just made it an example, we wouldn't have to test it in CR and we wouldn't have to go into great detail.
... downside is that we don't have a standard way of determining a minimum level of trust and people won't implement it.
... I favor defining it normatively and going into more detail if necessary.

Hugo: I like non-normative because normative requires great level of detail and security expertise and review from the security community.
... We don't have the necessary expertise in the working group. Rich and Abbie (security experts) agree.

Anish: Do you smell a note?

Hugo: We could make a note.

Anish: The note could provide those details and separate it from the timeline that we have here.

Marc: Someone will end up doing this. We are defining the protocol and should specify how we secure it. If we don't, WS-I or some other group will.

Anish: Do you think we need more details, and if so, should that be in the main spec?

Marc: Yes and yes.

Phillipe: Could it be made into an appendix instead?

Marc: A note would be acceptable. General standards consumer doesn't really differentiate.

Mark: So we have a packaging issue, but you want to have something you can normatively refer to.

Hugo: I would prefer not to have this in the main document. It will have a major impact on the timeline of the main document.

Paul: It would be useful if such a document was produced by CR for testing purposes.

Mark: If we were to decouple, would we want to include the non-normative in the spec and the normative in the note?

Marc: Yep.

Phillipe: We would need to invite other people.

<pauld> Philippe expresses concern about participation from security experts

Bob: There are many mechanisms, and they're very complicated, so I don't think that the normative version will work in this document.

Marc: I should point out that there is no requirement to implement security.

Bob: I don't think that a normative version can be right or complete for this document.

Marc: Having something rather than nothing seems valuable. It wouldn't be the only one, but it would be the one defined in the spec.

Mike: The second paragraph, doesn't seem necessary.

Marc: It was there only if we don't do anything else. If we have another note or something, it can go.

Mark: Seems like we're leading towards number 2.

<dorchard> I would have liked to say something like "If you are going to use ws-security, here's what you must do".

No objections, version 2 becomes basis of discussion.

Mark: To do a note, we'd have to write it and agree to publish it, but we don't need a charter change.
... If we wanted to make it a rec, we would have to consult the team, the group, etc.
... Notes don't fall under the patent policy, but recs do.

Mike: I think we should do a note, and include security, etc. almost like a primer.

Bob: These things will be used in a higher level protocol. Security issues are going to be relevant for these higher level protocols as well.

Marc: Yes, but there are specific things that ws-a introduces.

Umit: Why is it only limited to ReplyTo and FaultTo, shouldn't Action or ReferenceParams be included as well.

Marc: It does.

DaveO: I didn't like mandating security, but I would like to say if you use WS-Security, do it this way.

Marc: Second paragraph is ok, but I won't lie down in the road.

<mlpeel> I don't have a problem with it

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0115.html

Mark: Are there modifications/suggestions for any other part of Marc's security section proposal?

Hugo: The problem I had was point 2 said that to trust and EPR you need to trust the EPR source and that this source had to have authority over the uri of the EPR.
... However I may not have authority on the service, but you still might want to trust me, and therefore the EPR.
... There were 3 aspects for deciding trust (may not be exhaustive): trusted source, epr source has authority, address of epr is a trusted destination.

Tony: I'd be concerned about DOS.

Hugo: as rsalz put it, trust is not black or white.

Paco: How about Refps?

Marc: they're just opaque, right?

Paco: When we say the source, this should be the minter, but with refps this may not be the case.
... Isn't a problem to trust the source of the EPR and not care about the source of the runtime message?

Hugo: I always thought there were 3 actors: minter, source, and recipient.

Marc: It's who I'm getting it from that matters.

Bob: All the words around trust here have nothing to do with the application semantics of the message.

Marc: Not true, we say that the EPRs have to be cryptographically bound to the message.

Bob: round the clock trading use case. trust mechanism to authorize trading has dimensions well beyond signature of a particular message.
... We may be conflating the issues of EPR integrity and trustworthiness.

Marc: I don't think so.

Bob: I do.
... Is it proper to be concerned about the potential abuse of the EPRs independent of the security of the message?
... By combining them I think we're having conflicting statements.
... I don't think that we can trust a message just because we trust an endpoint.

Marc: I don't either, and I don't think we're saying that here.

Bob: It needs to be more explicity.

DaveH: Don't attribute to malice what can be explained by stupidity.

15 minute break. Will reconvene at 3:40

<dhull> (Meaning, some "security" scenarios can come up through simple mistakes, not just security breaches. E.g., bad code causes an authorized sender to flood the network)

<Marsh> (But in the name of security, we have to assume the worst...)

<plh-bedford> [starting again]

Resume discussion of Marc's security proposal

Paco: I'll send minor edits to the list.

Bob: The intro has to do with the fact that security implications for applications dealing with one or more protocols go well beyond anything we can state with these elements.
... Essentially it's trying to carve out that this relates not to the complete application or whole protocol stack, but is merely one part of the solution.
... It's kind of a disclamitory intro.

Mark: Any objections to that?
... Fairly editorial, so Marc and Bob will take care of it.

<prasad> I am good

Mark: Any objections to accepting the proposal as the resolution to the issue?

Hugo: My comment was substantive, is it included?

Mark: yes.

RESOLUTION: Proposal accepted as resolution to LC 87.
... Proposal accepted as resolution to LC 55.

LC101 and LC104

Glen walks through proposal.

http://www.w3.org/mid/80A43FC052CE3949A327527DCD5D6B27012975A9@MAIL01.bedford.progress.com

Prasad: It's not clear to me that core properties that are already defined can be extended.

Glen: You can extend the existing properties as well as add new ones.

<prasad> Good for me

<mnot> An endpoint reference is a collection of abstract properties. This

<mnot> specification defines a core set of properties, but it is also possible

<mnot> for other specifications to extend these and/or add other properties. The

<mnot> semantics and XML Infoset representation (see next section) for any such

<mnot> extension properties will be described in their defining specifications.

Mark: What about the pseudoschema issue?

Glen: Unless there are objections, I'd be happy to let it drop.

A discussion about the pseudo schema ensues.

Jonathan: You end up blowing up your pseudo schema, so I don't think it's the best place to define the extension point.s
... pseudo schema should be very constrained

Nilo: Is it necessary to add a cautionary note that any extension should not change the semantics of the core defined here?

<GlenD> Glen: Can we add something that describes (in the definition of the pseudo-schema) that extensions are omitted for brevity and may exist.

<prasad> think we allow that no?

Mark: I think the answer is no because we already tell people to be careful about that.

Umit: This proposal is only for 2.1 and about EPR, right? Not about the other MAPs?

Glen: Correct.

Anish: I found a pseudo schema related issue: For MAPs we don't express the cardinality, and I thought it would be useful to put it in there.
... Specifically, e.g. Action is one and only, but relatesTo cardinality is defined but not in the pseudoschema.
... My specific proposal was already posted to the list.

<mnot> LC 101/104

<mnot> Section 2.1, first sentence - replace with:

<mnot> An endpoint reference is a collection of abstract properties. This

<mnot> specification defines a core set of properties, but it is also possible

<mnot> for other specifications to extend these and/or add other properties. The

<mnot> semantics and XML Infoset representation (see next section) for any such

<mnot> extension properties will be described in their defining specifications.

<mnot> Before example, add:

<mnot> NOTE: Specifications which describe extension elements or attributes

<mnot> used to augment the above model will explain any effects those

<mnot> extensions may have on the abstract properties. They may affect either

<mnot> the core properties or extension properties as defined in section 2.1.

<mnot> In Notational Conventions:

<mnot> Clarify that extensibility is implicit in pseudo-schema

<mnot> <wsa:To>xs:anyURI</wsa:To>?

<mnot> <wsa:To>xs:anyURI</wsa:To>

<mnot> LC 101/104

<mnot> Section 2.1, first sentence - replace with:

<mnot> An endpoint reference is a collection of abstract properties. This

<mnot> specification defines a core set of properties, but it is also possible

<mnot> for other specifications to extend these and/or add other properties. The

<mnot> semantics and XML Infoset representation (see next section) for any such

<mnot> extension properties will be described in their defining specifications.

<mnot> Before example, add:

<mnot> NOTE: Specifications which describe extension elements or attributes

<mnot> used to augment the above model will explain any effects those

<mnot> extensions may have on the abstract properties. They may affect either

<mnot> the core properties or extension properties as defined in section 2.1.

<mnot> Section 3.2 example:

<mnot> add cardinality to pseudo-schema

<mnot> In Notational Conventions:

<mnot> Clarify that extensibility is implicit in pseudo-schema

Jonathan: I thought we had a link to the notational conventions in the WSDL spec.

Marc: It says to use BNF conventions

Umit: W3C should spit out a pseudoschema spec.

<mnot> ACTION: Jonathan to coordinate w/ WSDL to make sure notationalo conventions are synced [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action03]

Anish: In my opinion if you write a spec that claims it is extensible, then you have to show how it should be extended.

Glen: I wouldn't be averse to adding some kind of example.
... The issue for providing a framework is a separate one that is already closed.

Anish: I have a problem with how you can do extensibility with infoset.
... I don't know how to map that to abstract properties.

Glen: This just says that whoever extends the spec needs to tell you how to do it.

Anish: But you're making it someone else's problem.

Glen: But it has to be someone else's problem.

<Marsh> +1 to Glen. Extensions are by definition someone else's problem.

Mark: Does anyone object to the resolution?

Anish objects.

Roll call vote ensues.

<uyalcina> yep

18 yes

1 No

<hugo> the No vote is Oracle

RESOLUTION: LC 101 and 104 closed with the proposed resolution.

LC5

Mark: Several people mentioned that there were use cases around this property and removing it could be considered a substantive change.
... To remove it we still need to vote, but this kind of gives us an out.
... My opinion as chair is to mark it as a feature at risk so that we don't knock ourselves back to working draft.

Marc: Colleagues at liberty alliance are planning on using it.

Mark: We could mark it so, and get comments later that there will be formal objections if it's removed.
... The only argument against would be that we don't internally define any use for it.

Marc: True, but we do that for others as well. I'm just saying that we know it's necessary, why take that step.

<Marsh> +1 to mark at risk. We prefer to drop it, but not at the expense of the schedule. Marking at risk should flush out the constituency, or show it doesn't have one...

<Marsh> Proxy to Paco again. Back in 45 min, but you might be done by then...

Bob: There is a potential security use there.

<prasad> Wonder what action we would take if there is in fact an objection to removing the source endpoint

Marc: In liberty, they want to use the metadata bucket to add information about who the message was from.

<dorchard> +1 to "do something"

<Nilo> did he say comfortable or UNcomfortable?

<Nilo> i'd like to leave it in

<hugo> Previous discussion at http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item20

<pauld> chad, new poll

<chad> new poll

<pauld> chad, option 1: Flesh it out

<pauld> chad, option 2: Mark at risk

<pauld> chad, option 3: drop it

<pauld> chad, option 4: Status Quo

<pauld> chad, question: options for LC5

<pauld> chad, question?

<pauld> chad, options?

<RebeccaB> vote: 4,2,3,1

<mlpeel> vote: 2, 1

<marc> vote: 4

<dorchard> vote: 1, 2,3

<prasad> vote: 1,2,3

<TonyR> vote: 2, 4, 1, 3

<hugo> vote: 2, 4, 1, 3

<Nilo> vote: 4, 1, 2

vote: 2, 1, 4

<TRutt> vote: 2,3,4,1

<dhull> vote: 1, 3, 2

<GlenD> vote: 2,1

<PaulKnight> vote: 2,1,3,4

<pauld> vote: 4, 2

<jeffm> vote: 1, 2

<Paco> 2 4 3 1

<anish> vote: michael: 2, 4

<bob> vote: 1,2,4,3

<Paco> vote: 2, 4, 3, 1

<pauld> chad, count

<chad> Question: options for LC5

<chad> Option 1: Flesh it out (5)

<chad> Option 2: Mark at risk (9)

<chad> Option 3: drop it (0)

<chad> Option 4: Status Quo (4)

<chad> 18 voters: bob (1, 2, 4, 3) , dhull (1, 3, 2) , dorchard (1, 2, 3) , GlenD (2, 1) , hugo (2, 4, 1, 3) , jeffm (1, 2) , marc (4) , michael (2, 4) , mlpeel (2, 1) , Nilo (4, 1, 2) , Paco (2, 4, 3, 1) , pauld (4, 2) , PaulKnight (2, 1, 3, 4) , prasad (1, 2, 3) , RebeccaB (4, 2, 3, 1) , steve_winkler (2, 1, 4) , TonyR (2, 4, 1, 3) , TRutt (2, 3, 4, 1)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: First elimination round.

vote: 2, 4, 1

<chad> Eliminating candidadates without any votes.

<chad> Eliminating candidate 3.

<chad> Round 3: Eliminating candidate 4.

<chad> Candidate 2 is elected.

<chad> Winner is option 2 - Mark at risk

<pauld> chad, details?

RESOLUTION: LC5 is closed by marking the source endpoint and all associated machinery at risk.

Mark: Please come tomorrow prepared to wrap up any loose ends.
... We'll target final spec on Thursday, people can look at it and we can vote to go to CR on Monday.

Hugo: When we decided to use XML Schema and whether it would be normative or not, and limited ourselves to XML 1.0, because XMLP did the same.
... There has been push back. This would mean changing a couple of sentences in the core to say that we use XML 1.1.
... Our schema isn't as complex as say WSDL 2.0, we could just say that it's 1.1 and leave it.

Mark: This is the W3C looking at the overall stack.

Hugo: The pushback, we have linked certain versions of tech to certain versions of other tech and there's a cascading effect that is a problem.
... At an abstract level there is no reason to constrain to a particular version, but at a binding level certain specifics may want to be included.

Paul: We've cited versions for WSDL and SOAP, but not XML.

meeting recessed

Summary of Action Items

[NEW] ACTION: Glen to present a new version of the proposal for LC20 this afternoon [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action02]
[NEW] ACTION: Jonathan to coordinate w/ WSDL to make sure notationalo conventions are synced [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action03]
[NEW] ACTION: Mike to respond to Jacek [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/07/21 21:48:06 $