See also: IRC log
<scribe> Scribe: GregT
<mnot> http://www.w3.org/mid/[email protected]
Dims had a question about people making changes o EMR
to EPR
Issue 14 about relating metadata may be related... more homework on the issue needs to be done.
<scribe> ACTION: Dims will talk to William from HP
<anish> ACTION: Dims will talk to William from HP
EPR robustness - text went out on this.. Anish proposes closing 10 as dup of 23
Issue closed: i010 closed as dup i023
<anish> issue 10 closure proposal -- http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0121.html
Sanjiva has open action item in WSDL 2.0 to align action property in WS-Addressing w/operation name feature and default algorithm in 2.0 (it's a change to WSDL 2.0)
There is some coordination w/WSDL folks on this, and no change in ws-addressing side. Question is how to guarnatee uniqueness. If you own the domain name, you manage your own URIs in the domain.
<scribe> ACTION: Anish to propose text to clarify how action values should be generated (or implications of uniqueness in action values)
Anish will try to do by 12/20 (if possible, earlier)
Issue 15, redirection - owned by Marc Hadley. We need to keep this issue. The resolution about the meaning of replyTo indicates it has no meaning in the MEPs... or it only has meaning in the fixed MEPs that we define.
in other message, like a replyTo in a reply message, we aren't describing any meaning. Whether redirection is whether this is a useful usecase, or allow someone else to make up an MEP needs to be defined
It will stay open until we get the meaning of replyTo solidified.
Issue 20 - owned by Anish - Abstract adressing in ws-addressing don't map to WSDL endpoints (dependency on issue 23). Issue 23's meaning has changed. Can we restate this to be more concrete?
Anish - I don't think there is a dependency on i023. I can send a more detailed description if you want. Quickly, if you have an endpoint reference, and WSDL has endpoints, what's the relationship between the two.
Another sub-issue, what's the relationship between the value of wsa:address and value of wsdl endpoint that also may be included as URI within an EPR
Anish thinks this belongs to core since the construct is in core. The fact that you can have a WSDL port (or in wsdl 2.0, and endpoint).
Glen: another way to put this that these 2 needs to become aligned (not necessary the same thing)
<scribe> ACTION: Anish to describe this a bit more deeply.
Anish: my preferred proposal is to take the concepts in WSDL, and we shouldn't reinvent syntactic structure.
we should align it with what's in WSDL ...
The action should start getting discussed by early January
<scribe> ACTION: Anish to describe this (the mapping between ws-addressing and WSDL) and how the two get aligned more closely
Hugo thinks that an interesting question w/the currecn text, the metadata you get in an EPR is lower. If you get 2 EPRs w/the same reference address, and different policies (and they conflict), and you don't have any other source of policy, the spec says that the same policy applies to the endpoint (but you don't know which one) - since the spec says it conflicts. I can start discussion on this in the mailing list
Anish: this goes beyond policy. Similar, what happens instead of policy, there are different portTypes that are specified. Does that mean the EPR is a union of both?
Hugo: in the context of comparing EPRs, w/same address and same reference properties, it says it handles the same sets of messages, and has the same set of metadata. If EPRs are extensible, and somebody puts something else there (I don't know how we define policy), would this other thing be similar?
Paco: one point to keep in mind, the fact that you embed metadata, that doesn't mean that's all the metadata that there is. If they are contradictory, then someone must of screwed up. The fact that it's non-authoritative or stale, you should refresh it by another means
Anish: Paco, do you view EPRs as caching mechanism for metadata?
Paco: yes. Put it here so you have it handy. In case there is an issue, you may want to do something like use WS-MetadataExchange
Mark: 3 ways to do this (1) top-down metadata way for everything, (2) this kind of metadata use this way, that kind of metadata, use it this way, (3) use case way in this use case, use it this way...
Paco: need consistent way of rules for metadata is much easier (the global way)
Glen: when is the context when you would do this comparison? I have an EPR and it conflicts w/another EPR?
Paco: you may have something that's different, but my interpretation is that you should get higher-authorities to advise you what to do.
... EPRs are much more dynamic than WSDLs, so it's a bit different
Hugo: based on the definition of ref. properties, I guess they are equal.
Paco: some spec needs to be slightly updated to clarify...
... I was referring to where address and reference props are the same, all the metadata is the same. The metadata may be contradictory. In this case, you will probably see different EPRs for different partners (like different partner links), to freely manage the protocols.
Anish: if it's going to same address, and I don't want to use refps, what choice do I have? So that they don't go to the same entity?
... it may be ok to have conflicting policies in 2 EPRs (where the current spec says its the same metadata).
Paco: I'm not sure we want to change the way we deal w/these policies, because of this case.
You can always issue different EPRs or different refprops
Paco: I'm considering each EPR as a separate address for a channel, where a BPEL process isntance talks to different partners. If we brought in identity, they it would contradict it
Anish: I may not want to use ref props, and put the contextual information in the body of the message. As long as I maintain 2 separate verbs for the EPRs, I should be ok
Paco: You are overloading the address
Anish: but it's the same abstract address
... let's say I'm using SOAP, and it's the SOAP body, and it tells me who the consumer is.
... I'm trying to understand that the policy that may be included in the EPR is just a cache
mark: may want to step back. 2 EPRs that have the same destination and same refprops. If they had different portTypes, would that be an error?
Paco: as gudge was explaining, the endpoint may expose both of them. exposing one to different partners
Anish: EPR1 w/portType 1, and if epr2 w/portType 2, w/a completely different set of messages w/different policy, based on the message receiving, I would know what message would be sent. I am representing that by using 2 different portTypes.
Paco: I think you are saying that the endpoint is exposing both...
... one usecase where policy may be stale is endpoint changing their security keys and the information that someone has may be stale
... could be that policy could change over time.
Mark: another case is that you may have an update, combine policies to larger policy
Hugo will start the discussion
<scribe> ACTION: Hugo will work on issue 14
<pauld> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0000.html
Option#1 Status quo from the WS-Addressing member submission.
scribe: Cardinality of EPRs constrained in the core to
... 0 or 1 and therefore also in any derived bindings.
... Option#2 Original proposal - preclude use of multiple recipients
... in our current bindings. Unconstrained in the core,
... but no specific processing defined for multiple EPRs.
... Option#3 Cardinality of EPRs unconstrained in the core spec or
... bindings. No processing model defined for multiple
Paul: if we allow multiple replyTo, we would need some kind of precedence or marker
... to understand the MEP it's being pushed towards...
... If we chose option 3, people wouldn't be able to use these message properties, they would have to come up w/new ones
Glen: That may actually be a good thing
Paul: given the lack of interest on this issue, based on the replies to this date, we need to be very careful to get something working
Glen: from Sonic's pt. of view, we don't want to close any avenues to do itinerary routing on things
... I think it's ok to crisply define what stuff means, and allow people to build extensions - which is better than have people build waffley description on things...
Dave: 2 different ways to do this... say here's the one way, of doing things.. .and if you want to do something else, do something else. Another is that you have some extensibility, and stock receiver ignores extensions. And if they say you can do these kind of things w/these extensions, fine
Glen: but having multiple replyTo headers in a message, we wouldn't want to define what that means would we?
David: you can say, be careful if you do that, as you may not be getting the behavior you expect
Glen: I would rather see it say you can have a single replyTo, and if you want more, there is another header, which has 3 headers encapsulated, which define a certain meaning.
Paul: there are multiple ways to process this beyond the MEP (like do load balancing). My main concern is that we don't do what WSDL does, and keep things constrainted
David: sounds to me, what you are looking for, is if we can allow extensibility, to allow ws-addressing implementations, that's the sweet spot we are looking for
Paul: maybe I need to go away and ensure that we default correctly
David: look at what ws-security does in this space, e.g., how many headers exist in a certain role
Paul will go away and look at option 3 flushed out
Mark: the only thing I note is that 9 people want to continue on proposal 1, 6 for proposal 2, and no one for proposal 3.
Paul: I think this is a very important issue
<scribe> ACTION: Paul will flush out issue 9 a bit for proposal 3. Giving him to the next F2F will be good.
issue 8, ref props and ref params. To move forward, we need to have folks restate the problems w/current design, and how proposed solutions solve the problem
Glen had consistency, clarity, and safety
Rich brought signing problem
Anish brough up issue about composability
Mark would like people to go off and develop them a bit, demonstrate the problem as completely as possible, show the example, and then show how it causes a problem (e.g.,w/security related issue, or w/composibility), and then show how it solves the problem?
Glen: we've done this. Are there still people who are unclear on what these problems are?
David: I'm not clear that any of these approaches solve my security problem
<rsalz> Here is my note about signing: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0074.html
Glen: my security problem is specifically by speech acts being told to make those acts.
<rsalz> Can others (Glen,David) post the "major" link for their issues?
<GlenD> sec
Anish: are you expecting more proposals to show up?
<dims> GregT: that was me - dims
Mark: I think we have the space of proposals mapped out. I can see some proposals having ore depth
*sorry dims
Dims: I don't know if people think we need some kind of annotation
and whether or not they don't like the mechanism being proposed
Mark: 2 weeks ago, we took a straw poll on this, but roughly, 11 or so said we need to do that, and 6 said we don't. Last week, we did the same poll, and it flipped.
<GlenD> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0008.html
Mark: to me, that said a few people changed there mind.
Dims: is this a technical issue or not?
Mark: what I would like to do, is describe problems, and show solution, people can make a judgement on whether or not they are important enough.
Dims: so you need a set of scenarios for each of these?
Mark: yes... we need detailed scenarios that step through them
<GlenD> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0511.html
<GlenD> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0532.html
Tom: simple question, trying to understand the security issue, I guess I will put my questions to the list
Dims will do composability scenario
Glen will do the clarity/simplification one
Security one, we would like Rich to do (w/help from Glen and Dave)
Anish: on the mailing list, there has been plenty of discussion, and a few times on a call. Glen has provided criteria to compare 3 different designs. The only arguement in favor of the current design, is to use the SOAP processng model, and not reinvent it in a particular header. We have asked 3 times for the use case, but I don't recall seeing an exact use case for this
Mark: The point of contention, is people are saying we have these problems. Others say, no we don't.
... Don came in and gave his viewpoint of current design. The question is, is it so much worse? Do we need to change this?
Perhaps we need another process to state this a bit?
David: we just brought this up 30 seconds ago. If we want to meet our schedule, not everything in the spec has to be done at every level of every change on the spec. While I have a concern about security, I look at it as incumbant upon myself to prove strongly, that there is not only a problem, but a solution which is dramatically better than the status quo. I wouldn't look at where the burden of the proof would need to be
Glen: I think you are right wrt. the thrurst of what you are saying, however, I think the arguement for the change have been made a number of times already. To avoid excess work, if we can be convinced otherwise, we would stop and going away. If someone could explain it so we can get it, we would go away
Mark: if someone is willing to explain it, please step forward.
<GlenD> +1 Tom
Tom: what I came away after Don Box's talk, is that side affects happen, and if you put them inside of their own header, they will become ws-addressing specific. It's the first time I've heard that use case, but I think it's beyond ws-addressing.
<scribe> ACTION: Glen to write up proposal concretely on serializatoin problems for concrete/consistent
<scribe> ACTION: Dims to write proposal concretely for composibility scenario
<scribe> ACTION: Rich *hopefully* to write up proposal concretely for security problem (Glen to help)
Mark: does the notion of separating out formal identifiers from issue 1 make sense?
Paco: if we decide they weren't identifiers, where would issue 1 be left?
... does the spec really support that statement, that they are identifiers in the web sense?
... I think we went through what identifiers mean in the precise sense. Web identifiers and formal identifiers. Web identifiers you assume is a resource and can be dereferenced.
... if we say they are web identifiers, we are aligning ourselves w/them. like discouraging Aliasing...
... we should probably understand the meaning of identifiers, and what they are trying to do
David: the scenario that I am interested in, we barely touched on. EPR receiver, and get 2 EPRs from same source, what should they do. Second scenario, are 2 different sources, give you an EPR and they give you one that is roughly the same, what does that mean?
Bob: concerned/confused on debate. one element of EPR is a URI (certain identifier properties, in other cases it doesn't). Does it have more properties like a URN? Do the other referenced properties have anything to do w/addressing (like internal addressing within resources) that the web service is providing? I'm not convinced there is a fundemental collision w/web architecture. As long as treatment of EPR is consistent.
... therefore,if we can make a position statement (once we get passed whethere URI or URN is more natural), that we are using URI/URN in it's way it was intended, and reference parameters use some service to form behavior.
... a URN has some organizational persistence... (the way I read it).
Tom: my view of this is polluted (as I am in WS-RF). I see clearly, that people have a need for 2 EPRs to be paths to the same thing (and we want them to be different). All that people should be happy is that if they are equal, they are the same thing. I don't think we need the other property of having the operator there to say yes they are the same thing.
... is everyone happy w/the requirements that we don't have the full identity requirements? I think we are.
Mark: I think we are getting away from issue 1. If we don't address the relationship w/web architecture, we still have the concern (as it's part of our charter)
Paco: I think that one resolution of the issue, might be to realize that EPRs are not identifiers in a formal way, and one shouldn't be able to look at them and be able to operate on them like they do web identifiers. One may *think* we are identifiying web resources, but it's not so. Make it clear in the spec.
... on the other hand... I'm saying this as the intended uses that we see, they are in conflict w/core properties of web architecture wants from a URI. What Tom is saying is right, call it whatever you want, as long as we make the semantics clear.
... I realize what David was saying, he mentioned at end of F2F. These case may or may not be identifiers from different perspectives (client or server side). There are multiple lines to persue here (as we gain alot of insight)
David: I think that scenarios how a client gets an EPR and what it does w/a comparison, and in the context of ws-addressing means, is very interesting. I've been thinking alot of what Paco has been saying... and I think I support Paco. We need to continue to bounce approaches off one another. The brainstorming of approaches sparked different ideas and ways of looking at it.
Mark: I trust you are taking these forward.
Hugo: I'm unclear on whether this is about issue 1 or something else?
mark: Right now, it's about issue 1
<bob> phone flaked out
Anish: trying to understand the discussion of the F2F (isSameAs, isEquals)...
Mark: the answer is if you think we need to deliver an interface to allow folks to get back an answer whether they are the same or not, then you think we need a mechanism to identify formal identifiers
Jeff: I think the debate about what's being identified is a red herring
... if we require sameAs service required as implementor of EPRs, it's up to the service to define that. What that resource assumes or what the semantics are is dependent on whose implementing that resource
Rebecca: you were saying status quo is that we aren't using EPRs as identifiers, but it's listed throughout the existing spec
Mark: Instead of identifier, it's more a formal description of identity
Straw poll: pretty strong indication that we don't want to declare formal identifiers
Mark: to move that forward, question is, what's the relationship between EPRs and web identifiers. Many people are using EPRs to identify web services endpoint. If we are going to say that they are not identifiers, we need to come up w/some justification. David/Paco, you guys had some thoughts here?
Paco: I think it helps clarify what we are saying by narrowing down what we mean by identifier, and what we mean by web identifier, and it's not a good thing to do
David: I answered don't know on the straw poll, as I think it's a bit early. Some of what jeff said has resonated w/me. If it turns out that Jeff's concern on what we mean by identiy show up, and are problematic, then we can deal w/it.
mark: We can ask the tag what they mean by being identifiers.
<scribe> ACTION: Hugo to start discussion on what and how many things we are identifying