WS-A F2F, December 8, afternoon session. Scribe=Steve Winkler from SAP. Note: I tried to capture as much of this as possible, but sometimes the dicussion became heated and went to fast or involved whiteboarding that was hard to capture. I've marked below places where I was pretty sure I missed something and it would be helpful if those people could clarify (if the can remember) what they meant. Note: Also, there were 2 marks present and I may have mixed them up, so if you feel that you've been misquoted, please let me know. Topic: ISSUE i001 - EPRs vs Identifiers Possible solution proposals: DaveO: Explain the tradeoffs of EPRs versus URis and justify why we really need identifers in EPRs. Paco: They aren't identifiers and we need to change language to reflect that EPRs don't have identity properties. Hugo: We should get rid of ref props and their functions as identifiers. -------- Discussion ---------- Tom: Can I get some clarification, are ref params a part of this discussion? Jeff: The only difference between refprops and refparams is that you are allowed to use one in identity comparison. Paco: The spec states props change the metadata and params don't. This has nothing to do with identity. DaveO: Params can also be used as part of an identification structure, but WSA is written such that the things you look at, like metadata doesn't change. Users might claim that a particular param identifies an instance, but within their own implementation. So they will be used as identifiers, but within the implementation. MarkN: section 2.1 sentence ends 'being conveyed' which is confusing and should be looked at later. hugo: ref params not used for identification, with the way the spec is written, so I don't have a problem with ref params. Paco: If params don't identify, you don't have an issue... Tom: Different params can indicate diff resources, but not different metadata. ref props help you find the type, and params help you find a different instance, and both are valid. DaveO: I agree, this will be used to identify instances, primarily within the context of state. Tom: Different props indicate different schema, this is confusing to me. Paco: If the props are different you can't assume that the schema is the same. It's not necessarily different, but you can't assume that it's the same. MarcH: What are the implicatiosn of whether they are an identifier or not? Paco: If they are, we assume that TAG will have a problem. MarcH: But what is the technical difference? Paco: If they are identifiers they have to be unique, comparision has to result in (in)/equality and in the main EPR use cases this assumption would be wrong. If EPRs are different in comparison, then they should point to different resources. Bob: You can prove equality, but not inequality. MarkN: Paco is saying EPRs add to the web arch that you can have 2 EPRs that point to the same thing? Paco: The TAG assumes this may happen, but they try to avoid this. With EPRs in our spec we want to do this. URIs are not being used as identifiers in practical use, they don't imply identity. DaveO: Web arch says that as a service provider, if you use aliasing, problems may result. If you want to have 2 structures for the same thing, that's a feature. Paco: If we say EPRs are identifiers, they will be compared and wrong conclusions will be drawn because they're not implying identity. Paul: A URI gets me to a resource, and a different URI gets me to the same resource, but it doesn't get me to a diff resource. It's a many to one. Paco: Web arch says that it's not desirable to have multiple URIs pointing to one resource because you lose identity. Paul: It's not really an address, but it's directions how to get there. It was a place to send messages, but you had no assumption as to who was going to receive the message at the address. Jeff: It depends on the comparison function. Paco: Through comparison we need to be able to identify. MarkN: So you're raising the bar, and saying even though the web allows this, we shouldn't. Paco: If you have 2 pointers to the same thing, they aren't as valuable as if you had 1 and only 1. Jeff: Let's go back to first prinicples - an identity is an equivalence relation. You have i1 and i2 and some function sameAs which returns a boolean. boolean identity = sameAs(i1, i2); Gudge: Isn't the result of the function really yes, or 'don't know' and not really a boolean. Jeff: In a true identiy it should be a boolean, but this sameAs method is context dependent. E.g. a replication servicehands out services etc., clients of the replication service must consult some delphi to find out that two received services are the same, but if you consult the replicant service, they aren't. The context is provided by where you do your consultation. You have to consult somebody, a factory or a table or something. Paco: I agree, but you have to define the consultation method, otherwise this is broken. Jeff: As a client, I aquire 2 structures and I want to determine if they are references or if they identify the same thing and I need to ask somebody to find out. Paco: But since we're not going to provide that here, we should refrain from doing this. DaveO: But the web arch works good enough, so we don't really need... ScribeNote: Sorry, the discussion was moving fast and I lost the thread here. Anish: Paco doens't want EPRs to be identifiers because he doesn't want people comparing EPRs, but the spec says how to do this. Paco: But not for identity. It's misleading to call these identifiers. MarkN: The reason we need props is that they identify a context, so I'm not sure this will get us anywhere. Jonathon: There is no universal comparison for namespaces, you do it char for char, but that doesn't necessarily guarantee what they point to. DaveO: If a website issues a.org:80/index.html and it issues a.org, within the server they can be the same resource. They are different ids. That is the comparison function (string comp). They identify the same resource on the server, but the strings are different. What are the downsides? When a comparison for equality is made they get a no answer, the server pays the price. Say you are cacheing, the server has to do 2x the work. You want the identities to be the same is so that the comparison can be true, and they can offload the work. This is why the webarch doc says that this is dangerous, but it might be ok, and this is why the web works relatively well and we didn't need to provide a compare method. We could have done this canonically but we didn't because it's in the interest of the URI provider. If you want to say that an EPR is an id, what is an id? The reason you do a comparison is that you want to know that they are not equal. If we say you can compare the EPRs using our compare method and they are different things --> if it hurts, don't do it. Paco: So your point is that the server has perogative and interest in ensuring the ids provide value, what about the clients? Jeff: The client would like to know that they aren't paying the same person 2x when paying a list. Also, EPRs are aquired from different resources, but maybe the resources may be accessed via several hops. Glen: I like a lot of what Paco was saying. It's not really a good idea to think about these as identifiers, but the wording around params and props seems to do exactly that, which makes hugos argument interesting. Paco: The infrastructure can do what they want, but I was trying to make clear to clients what they can expect when they compare EPRs. Tom: Just for clarification, are both params and props used for comparison? Paco: There is no comparison of that kind. Dims: In this discussion, are params and props the same thing? Paco: There is a question between params and props but let's separate that issue from this discussion. Gudge: (Writes a complicated table on the board) Gudge: Compares several use cases. same metadata 1, 2, 3 same serialization 2, 3 different metadata 4? same identity 2,3, 1?, 4? Scribe: (waves hands in frustration and gives up - sorry gudge, I couldn't quite get all of this) Gudge: What's the answer for 2,3 for same identity. What it comes down to is what is an identifer? Paco: We don't need to answer this, 2, 3 are out of scope. Anish: (adds porttype service qname, policy, etc to complicate table) Anich: Are 2 and 3 are still the same EPR? Gudge: yes, whatever that resource is supports A and B. Hugo: My interpretation is that 1,2,3 are the same endpoint processing things that would be called a service. DaveO; The EPR minter should not issue EPRS 2 and 3 with different policy statements or port types if they expect that people will be comparing them for equality. Greg: Who is to say that policy doesn't specify that defines whether to use P or Q, it may be the superset of all of thethings to be used. Anish: What does an EPR represent? Greg: It represents how to get somewhere and policy tells. Gudge: EPR defines what to put in the to and the headers when you want to send a message to that EPR. Hugo: Why do we have a diff between prop/param? Gudge: Because we know certain things about metadata if one is the same. Paco: Metadata, policy, etc., needs to be linked to the EPR so that the client can know what they need to comunicate with an EPR. Metadata can't capture all runtime dynamic stuff, this won't be in the WSDL. Jeff: Is TID part of that identity or not? ACTION: Gudge to redraw his chart with more columns, put some text around it, and put it on the public list for discussion via email. Tom: I'm confused about why portype is in there if it doesn't really matter? If there's a difference in parts of the ERP and this is important to identity, this needs to be clarified but that's not how I originally read it. Bob: Fundamentally the only thing that matters is the behaviour of what is behind the EPR. Jeff said that in some systems you have an authoritative source to consult, or multiple, but in this case you only have the thing you are accessing. There is no way to compare the behaviour of 2 or 3 EPRs. My concern is that we're not going to be able to get through the issue of bit/bit comparisons to absolutely properly test the identity. The service itself needs to come up with a way to declare its own behaviour, e.g. a behavorial serial number or guid that could be returned and this could be compared, but there's no way short of that to do this with EPRs in today's state. Jeff: What is the contract that you make when you hand out EPRs. What are the contracts? Conclusions can you draw? Gudge: Why do you have to compare things to be able to use it? Jeff: You don't, it depends on what you want to do - reference to Jeff's previous payment example. Harris: The server knows what to do when it receives to requests with different URIs to the same resource, the service should know what to do. Discussion could be moot Paco: But it's the client that needs to know. Harris: But props are opaque. Paul: We're doing this because we've got to go before the judge. Pacos saying we're guilty and Dave is saying we're guilty with mitigating circumstances. In essence, I think of an EPR as a to address or a mail header, but there's a bunch of other stuff that we send with it. I make no assumption about the content, but the recipient should be able to know what to do with it. We're just giving people drirections where to post. Action is another part of this, but why aren't we concerned about this for routing? Mark: it's a URI ;-) ------ 15 min Break ---------- topic: Dave's approach to the issue i001. DaveO: In reference to web arch, we can look at: extensibility defined in webarch. Defined based on get in http. Costs due to introducing new id mechanisms, benefits must be high to do so. URI spec defines a resource to be anything that can be identified by a resource. They just didn't want to use 'things'. MarkN: Interesting history, when TBL took this to IETF, it was universal resource id, and now it's uniform resource id, due to pushback from IETF. DaveO: We don't need to say what an EPR identifies, we just need to figure out whether it is used as an identifier. the member submission, dyanmic, id and descr of service instances, etc. etc. (see email). DaveO: It's important to note that webarch doesn't discuss stateful vs stateless, leaves open/extensible, nor does it discuss cookies. It also doesn't talk about post results, they're not ided by uris. I'll try to focus on EPRs with props/params, but there are obvious parallels to http cookies. The same kind of benefits will apply. Let's say they are ids, let's show the costs/benefits. Scribe: All of this is in Dave's proposal email so I'm not going to retype it here. Mark: Please limit questions to clarification at this point. Anish: Scalability, essentially they are the same, but visibility they are different. It seeems to me that visibility will affect scalabiltiy ,especially because refps are supposed to be opaque. DaveO: Scalability is how many additional components that can interact with me. Anish: What I'm looking at is, if it's just a URI which isn't necessarily opaque, the ability it gives me is that I don't have to go back to the original minter and I can just use the URI. With respect to EPRS, given the opacity of refps it prevents me from changing anything in the EPR and reusing it. That's the scalability I'm looking at. DaveO: The EPR portion of the spec doesn't provide any authoritative URI description as well, so it's opaque to. Anish: If WS-A were to make the same statement as web arch with respect to authortative metadata for creating URIs with EPRs... DaveO: Someone could provide an extension stating explicitly how they are filling refps, and constructing eprs so users would know. As it stands we don't do that in the spec so it's opaque. Anish: I'm disallowed from providing you the additional information, that's how I read the spec. With URIs that's not the case. With refps we explictly block this. DaveO: Isn't that what WS-RF is doing? Paco: If you're a client and you get an EPR, WS-A says you don't know how they are constructed. Anish: The spec explicitly calls out that this is opaque and you're not allowed to describe it. I just want to be clear on this point, but it's not a deal breaker. MarcH: Can we talk security? I'm not sure what you're saying, can you encrypt or sign a portion? Dave: Yes, visibility is a 2 edge sword. If you selectively encrypt/sign EPRs or parts of EPRs you can gain utility. It's similar to HTTP GET vs HTTP POST. Post allows you to hide user/pass whereas GET puts it in the uri and makes it visible. MarcH: But you do that anyway with the To header. Dave: You're saying that the To header is part of the message anyway. MarcH: Do you have a specific use case where you want to sign/encrypt a particular part? Dave: good point. Tom: In the examples, the variants are different, would these differences be reflected in the WSDL? DaveO: The interfaces are the same, the difference is in the deployment. You're deploying them at effectively different addresses. Tom: The second one, all three ports have the same address. DaveO: In the second, you have one piece of software that manages all parts. This brings up a significant advantage, in that you take advanatge of the soap processing model, so you can look at the headers easily. You can write a really easy Xpath to find what you're looking for, but we don't have a structured library to find soemtihng like this in a URI. We get kind of a preprocessor and don't have to microparse. Yinling: Additional cost is also echoing ref p. Is this because of that specific scenario, or is it for all refps? DaveO: The incremental cost is that you have to echo it. You still have to understand replyto, etc., but I'm still going to have my soap model, etc. YinLing: You may have other scenarios where you don't require echoing. DaveO: Yes, but if it's a required part of WSA then if you get a EPR from me that has, you have to support it. MarkN: Ok, so we've got 3 characters from proposal 1 -> Hugo=guilty with execution. Dave=it's only manslaughter. Paco=the glove doesn't fit. Straw poll: Are we identifying something with an EPR? Yes: 9 No: 5 Unsure: 3 MarkN: Should we go forward with issue 1 by structuring a comparison between EPRs and identifiers, or go forward by changing the language of the spec to reflect that they aren't identifiers, or both? DaveO; The address field might be different. What happens when everything is different and the message still gets routed to the same resource/piece of software? If it is an identifier, what is it identifying? It is not identifying the resource, it is identifying the protocol and the information necessary to access it. It's further towards the client and you don't want that comparison. It's somewhat of an access channel. Hugo: Whatever we call it, I think it's an identifier. We're only focusing on webservices use. How could I use this not in the context of a soap message, e.g. to make assertions, etc. Address and identifier is the same for me. Jeff: EPRs are used for a lot more than the mechanical comparisons that paul mentioned. People are going to hand out EPRs and they'll get passed around, they contain metadata and whole lot of other stuff, much more than how to put the message on the wire. If we want automated systems to do pass these around and represent web services, with state, then we have to provide the sameAs function. Paul: The reason behind the discussion is that we're using EPRs for 2 reasons. One is passing around headers, etc., and another is for identification. What if we split this, would that help? Jeff: In a distributed system that doesn't work. Straw Poll: Who thinks we need to tackle identity problem? Yes: 9 No: 9 don't know: 2 Jeff: I'm interesting in doing something concrete. I just want answers. Tom: The concept of an address needs props, params, and action. There are additional things you need but not for dispatching. Gudge said these 3 go on the wire. The problem is that we're using the word address for only one of these definitions. The fact that the spec only uses refprops is another point. Harris: The only Use case I've heard so far for comparison is for cacheing. I'd like to hear about comparing 2 EPRs for identity. Glen: Hugos question should be addressed before this one. If we resolve that by removing refprops then this issue might go away. WSDL has the same issues exactly. They have a model, these are services, these are endpoints. EPR is based on endpoint, so we should describe EPRs in the same detail and granularity that WSDL does. MarcH: Getting back to the EPR comparison function that Jeff mentioned. I think this would be simple. Define a porttype that every WS-A capable service has to implement to provide the comparison. Anish: It would improve interopability. Gudge: My question to jeff is, are we trying to deteremine if 2 EPRs are the same or the thing that is addressed by the EPRs is the same. Jeff: The latter, but note that sameness is context dependent. reference the earlier behavioral discussion from bob and replicator dicussion from jeff. MarkN: If you don't know those contexts, how can you define them? Why do we need to define them? Gudge: The big problem is that half of us thinks the former and half of us thinks the latter. If I do a bit comparison for 1 and 2 and they are the same, I don't need to re-retrieve metadata for 2. DaveO: Use Case -- Got tx service at A, has some method createContext. 1. A 2. A with refprop=foo. Receiver says, ah, there's a difference, so there may be different metadata. The interface could be different. One could be createContext the other could be the 2phase commit protocol. Harris: refprop is opaque, so he doesn't know. DaveO: but if he's going to do something, and he knows the metadata is different, he may need to do something different, but that's out side of the scope here. 3. A with refprop=foo, refparam=dave. Interesting comparison in 2 if he gets 2 EPRs back with different refprops and he (the client) can choose. When 1 gave back 2 he said that both were equal, resulting in an effective sameAs function. It's an implicit compare instead of explicit. Jeff: I think there are cases where you need explicit. Say you get the 2 EPRs in line 2 from 2 different services A1 and A2. Dave: I described bifurcation, 1 -> 2, and you're talking about unification, going from 2 -> 1 and I'm struggling with that. MarkN: This is the use case (daveos bifurcation) that motivates the current design. Hugos suggestion invalidates this usecase. Anish: +1 to glen about us defining EPRs and WSDL defining endpoints. We need to look at that. Paco: Glen was saying if we go with hugo this issue goes away. That's not true. It doesn't deal with our requirements, and it doesn't help with identity and we're just stuck with URIs -> web arch. The other thing about Tom and action, we have a set of messages, and we can address multiple messages to an endpoint, this is why action is not part of an address. Rebecca: First, an aside - action for dispatching implies that it is part of identity. Next my real point - It seems that there are 4 basic terms of identity; 1. They are the same on the wire format. 2. Identity meant using the same channel to get to a service, which means assuming the same processing. 3. Identity meaning same service, in a distributed environement that could be in different places, but doing the same thing. 4. Identity can mean the same code, so you end up at the exact same code place. You're never going to get these 4 unified, so why don't we have 4 compare methods, one for each. MarkN: follow on question - which of those do we need to do? Hugo: My proposal, reusing dave's, instead of receiving 2 EPRs, you could receive 2 URIs. Dave has started a structured comparison of the 2 solutions. Dave is saying the TAG isn't saying don't do this, but you have to have a good justification for doing this. I assert we havne't gone there yet. There was always a way to do it with URIs, and this is another way. It has marginal advantages, but it doesn't justify a new identifiaction mechanism on the web. The cost of introduction is very high. DaveO: What is the cost? Not the benefits of another way. Hugo: It's an opportunity cost. DaveO: We've already got a soap processing, WS-A has a reply to, the only cost here is the echoing ability. New software has to be built for that, but that's it. Hugo: Down the line, I'd like to make assertios about ERPs. You're saying, we do what we do without looking at what others are doing. If others want to do RDF assertion, then we'll need to come up with another way. Here's the first problem, then they'll ask for XForms. Hugo: my proposal is to remove reference properties from the EPR. MarkN: How do you hanlde different meta data? Hugo: Different URIs. Anish: If we do that, we still have params. Hugo: To me, params are just for state. Scribe: (general grumbling permeates through the room) Tom: Right now endpoint is the thing behind the URI and WSDL is using endpoint as the URI. We don't want to have different names for those. Hugo: I'm unclear about params that identify. Hugo: I think I have to rethink my proposal with respect to refparams. Straw poll: Should EPRS be identifiers? Yes: 9 No: 7 Unsure: 2 DaveO: There's a difference between whether a server or client is doing the comparison, so maybe Paco and I are both right. Harris: +1 Jeff: We also might wind up in a place where URIs are, where they are identifiers but they aren't semantically correct. Jonathon: Let's condense our behavioral idea of what we want to achieve first. We need to look at the requirements.