Doug, I think I'm connecting, if you'll pardon the pun. 1. As I read WS-A, the [destination endpoint][address] must be set to [reply endpoint][address] for a reply. 2. If [reply endpoint] is omitted (as per the CD example), then [reply endpoint] = anon, by default. 3. If [destination endpoint] = "anon-URI?id={uuid}", then [destination endpoint] <> [reply endpoint][address] (which was simple, unornamented anon-URI), which contradicts premise 1. Does that make sense? If so, then I think you would need to set [reply endpoint] to none, explicitly, to avoid that clash (given RM's current approach). But this causes 4. The WS-A processor that sent MakeConnection to get very confused. It wasn't expecting anything but an HTTP 200 series by way of a response, but is about to get a full-scale SOAP message bounding back. +++ Further thoughts, which continue, in my mind, to question the current RM approach, but which may ease the WSA W problem. a) You could have defined an extension element in the [reply endpoint] for the UUID. b) Or, you could have chosen to send the UUID in the body element. c) In either case, this could team up with setting [reply endpoint] to anon. d) As in 3. above, you shouldn't then set response [destination endpoint] to anon?id={uuid}. e) So, you need to set [reply endpoint] to anon, /and/ set [destination endpoint][address] to anon. f) which begs the question, where does the UUID go? g) If you passed an extension element UUID, or a UUID in the body element, and then passed it back as an extension element in the anon EPR that should be OK, because you have followed the rules for reply formulation with respect to the [destination endpoint][address]/[reference parameters]. The fact you have chosen to put an extension element in the response is WS-A 3.3/3.4 legal, as I read it. That's a higher-layer behaviour that does not contradict WS-A base behaviour, which is constrained. +++ Why is g) not viable in your view? The processors that need to understand the body/extension UUID element are the RM senders and responders (not the WS-A processors, which passively pass on the UUID to the RM receiver of MakeConnection, and pass on the extension element to the RM receiver of the response). In other words, the awareness of RM-ness that is demanded in formulating MakeConnection, and in replying to it, resides in the same place, and at the same level, as in the current (CD) solution. The difference being: that the MakeConnection is now a regular [reply endpoint] = anon. At which point special WSAW rules are not needed. I don't see any lesser or greater problem with intermediaries, onward transmission etc than would apply with the current solution, if that is a concern. On this point, I think I may be missing something, or misunderstanding your area of concern? So, to summarize: 1. asimple-non out, special, ornamented-anon back is a problem. 2. none out, anon back is a problem. 3. extension element UUID out, extension element UUID back, is no different, in layer terms, than body UUID out, ornamented address back, i.e. is not a problem. 4. anon out means no problem with anon = required. * * * My last point was indeed completely beside the point of your issue :-) -- it is an independent issue about WSAW, and a limitation that the proposed syntax seems to impose by applying the flag across all "response endpoints". Alastair Doug Davis wrote: > > Alastair, > We did consider adding some extra metadata to the EPR (outside of > the wsa:Address and ref-p's), but there's a problem - this metadata is > not copied over into the response message - just the wsa:Address and > ref-p's are. This means that any data placed elsewhere in the EPR is > lost once the message is serialized. So unless we assume the impl can > hold on to the original EPR for the entire message path (which we > can't in distributed systems), the identity part must be in either the > address or ref-p's. And, as you said, ref-p's aren't good for this. > > What's interesting about your anon?unique-id example is that that > solution might work very nicely (we talked about this in the past) - > but as you said it would require WSA to say anon URIs 'start with...' > - and WSA is closed :-( > > I got a bit lost on your last point - it almost sounded like a > complaint about the current WSA WSDL spec instead of my issue - or > did I not follow it? > > I noticed that on the agenda for tomorrow's WSA call (I think its > tomorrow) is a CR issue that mentioned how this wording in the WSDL > spec prevents the use of "none". I can't help but think that both > issues (mine and the other CR issue) would be solved nicely if the > wording were turned around a bit and said something about how this > flag indicates whether or not the endpoint supports addressable > endpoints in the response EPRs. Not sure of the exact wording, but if > instead of taking about specific URIs (like anon and none) it talked > about whether the endpoint supported the notion of creating it own > connections to the EPR then it wouldn't need to get into the business > of listing all of the URIs that are valid. And I think it would relay > the exact same information. > > thanks > -Doug > > > > *Alastair Green <alastair.green@choreology.com>* > > 08/04/2006 10:57 AM > > > To > Doug Davis/Raleigh/IBM@IBMUS > cc > public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, > ws-rx@lists.oasis-open.org, abbieb@nortel.com, aclark@novell.com, > akira.tanaka.pr@hitachi.com, aleyfer@actional.com, > anash@reactivity.com, andreas.bjarlestam@ericsson.com, > anil.edakkunni@soa.com, anil.john@jhuapl.edu, > Anish.Karmarkar@oracle.com, Anthony Nadalin/Austin/IBM@IBMUS, > asakala@iona.com, ash@rainingdata.com, ashok.malhotra@oracle.com, > asirveda@microsoft.com, atarashi@sv.nec-labs.com, atmanes@gmail.com, > audet@nortel.com, barreto@adobe.com, bhakti.mehta@sun.com, > blake.dournaee@intel.com, bob.freund@hitachisoftware.com, > bob.sunday@pwgsc.gc.ca, b.eckenfels@seeburger.de, > carolina.canales@ericsson.com, chamikara@wso2.com, > chappell@sonicsoftware.com, Charles Levay/Raleigh/IBM@IBMUS, > chouthri@sv.nec-labs.com, Christopher B Ferris/Waltham/IBM@IBMUS, > Christopher.Kurt@microsoft.com, chris.hipson@bt.com, "'von Riegen, > Claus'" <claus.von.riegen@sap.com>, coevans@microsoft.com, > cunningham_david@bah.com, dan@actional.com, "'Burdett, David'" > <david.burdett@sap.com>, dconnelly@openapplications.org, Diane > Jordan/Raleigh/IBM@IBMUS, dkmin@konkuk.ac.kr, dleshc@tibco.com, > dmoberg@us.axway.com, dnickull@adobe.com, "'David Orchard'" > <dorchard@bea.com>, doug.bunting@sun.com, > eisaku.nishiyama.dd@hitachi.com, email@cbvenkat.net, > eoghan.glynn@iona.com, Eric.Newcomer@iona.com, > eric.rajkovic@oracle.com, eric.wells@hitachisoftware.com, > ganga.sah@oracle.com, gatfora@uk.ibm.com, gboschi@sonicsoftware.com, > gdaniels@sonicsoftware.com, "'Gilbert Pilz'" <Gilbert.Pilz@bea.com>, > girish.juneja@intel.com, gregcarp@microsoft.com, > greg.pavlik@oracle.com, hbenmalek@us.fujitsu.com, > heiko.braun@jboss.com, ian.c.jones@bt.com, ian_robinson@uk.ibm.com, > james.speer@capgemini.com, jamie.clark@oasis-open.org, > jdurand@us.fujitsu.com, jeff.mischkinsky@oracle.com, > jekanaya@cs.indiana.edu, Jiri.Tejkl@systinet.com, jjchoe@tmax.co.kr, > jkchoi@methodi.com, jmarsh@microsoft.com, > joeri.van_cleynenbreugel@alcatel.be, john.gotze@oasis-open.org, > john.kemp@nokia.com, joseph.2.waller@bt.com, junghc@nca.or.kr, > jypyon@nca.or.kr, k-seki@da.jp.nec.com, kcyee@cecid.hku.hk, > kiwasa@jp.fujitsu.com, lburch@novell.com, lily.liu@webmethods.com, > "'Lei Jin'" <ljin@bea.com>, machi@nca.or.kr, "'Mark Little'" > <mark.little@jboss.com>, "'Schenecker, Mark'" > <mark.schenecker@sap.com>, "'de Boer, Martijn'" > <martijn.de.boer@sap.com>, "'Raepple, Martin'" > <martin.raepple@sap.com>, mary.mcrae@oasis-open.org, > matsuki.yoshino.pw@hitachi.com, mckierna@uk.ibm.com, > mgoodner@microsoft.com, mhb@itst.dk, "'Bechauf, Michael'" > <michael.bechauf@sap.com>, mike.grogan@sun.com, millwood@uk.ibm.com, > mlovett@uk.ibm.com, mlyons@layer7tech.com, mschenecker@e2open.com, > mwang@tibco.com, nickr@enosis.com, nilo.mitra@ericsson.com, > nobuyuki.yamamoto.vw@hitachi.com, Ondrej.Hrebicek@microsoft.com, > paul@wso2.com, pauld@mitre.org, paul.cotton@microsoft.com, > paul.knight@nortel.com, peter.furniss@erebor.co.uk, > peter_niblett@uk.ibm.com, pete.wenzel@sun.com, > prateek.mishra@oracle.com, pyendluri@webmethods.com, Richard > Salz/Cambridge/IBM@IBMUS, robin@oasis-open.org, sada@jp.fujitsu.com, > "'Patil, Sanjay'" <sanjay.patil@sap.com>, sanka@wso2.com, > scayron@acord.org, Scott Hinkelman/Austin/IBM@IBMUS, > shengsong.ni@oracle.com, shivajee@tibco.com, srcarter@novell.com, > stefanba@microsoft.com, "'Rossmanith, Stefan'" > <stefan.rossmanith@sap.com>, "'Winkler, Steve'" > <steve.winkler@sap.com>, sumit.gupta@oracle.com, > tboubez@layer7tech.com, tejeswar.das@iona.com, > thomas.erl@soasystems.com, thomas.t.bui@boeing.com, > timothy@drummondgroup.com, toby.considine@unc.edu, tom@coastin.com, > "'Yalcinalp, Umit'" <umit.yalcinalp@sap.com>, vfurman@webmethods.com, > "'Shipkowitz, Vicki'" <vicki.shipkowitz@sap.com>, > vikas@sonoasystems.com, "'Videlov, Vladimir'" > <vladimir.videlov@sap.com>, Martin Chapman <martin.chapman@oracle.com> > Subject > Re: Comment on WSDL spec: use of Anonymous Element > > > > > > > > > > Hi Doug, > > Comments interspersed: > > Doug Davis wrote: > > Alastair, > There are a couple of different things at play here. First, sorry > about the long cc-list but the wsrx mailing list still doesn't appear > to work so I need to include the entire wsrx team manually :-( > I thought my mail client was going to expire when I just did "reply all". > > In a non-anonymous world the wsa:Address field represents both the > fact that the destination can access connections and it identifies the > party. And I think that makes sense. There is no reason to not have > a single URI do that (let's not get into the 'identity' issue w.r.t. > ref-p's :-). So, if we then switch over to the anonymous case, IMO, > I don't believe the implementation should need to change w.r.t. the > purpose of this URI. > Here's what I don't understand. In the non-anon case an EPR (address + > stuff) is used to target. In the anon case, so far as I can tell, > there is nothing in WS-A to stop the same "full EPR" (address + stuff) > being used to target the reply. > > If one pursues this, what you intuitively want is: callback EPR = > {address = anon URI, ref-param[0] = identity}. > > But ref-params are opaque. Not what you want. (Although I can't see > how to stop an app contract, e.g. RM, specifying that we'll use a > mutually-known type for a ref-param, and make its presence mandatory > for certain messages). > > Assume that ref-param is not good. Why not add an RM extension element > to the EPR? This retains the identity lexeme within the EPR. A WS-A > impl should be happy to insert and extract such extension elements, > even if it hasn't a clue what they mean. > > In the simple WS-Addr anon use-case the URI still indicates both > things - whether or not (and 'not' in this case) the destination will > accept a connection, and it also indicates the identity - sort of. > The identity is implicitly defined by the fact that it is tied to the > connection on which the request came in on. If we did what you're > suggesting and add a second header then, IMO, RM would require quite a > big change to people's soap processor. I think WS-Addr did a really > good thing by keeping everything people need to know with a single > structure - the EPR. Even with the introduction of the anonymous URI > (which could very easily have been introduced in a much less cleaner > fashion), most of the SOAP processor doesn't really need to know what > the specific value of the wsa:Address element is until it tries to > actually send the message over the wire. > So, if we then switch over the MakeConnection use-case, I think RM > did the right thing by using the same mechanism WS-Addr did - keep > everything within a single EPR. > OK, but I think you may be conflating "a single EPR" with "the address > element of a single EPR". > > This allows for most of the SOAP processor to be totally unaware of > the actually transport mechanism until (or close to) the time the > message is serialized on the wire. If there were additional headers > to carry this information then existing WS-Addr logic of mapping a > wsa:ReplyTo over to a wsa:To + ref-p headers when constructing a > response might need to also change. There's also lots of other > use-cases where the logic to handle the RM code isn't on the same > machine doing this WS-Addr mapping so if its not aware of RM at all it > wouldn't even know to include some special bit on the outgoing message > (either in the message or in the soap processor's metadata about the > message) to indicate that MakeConnection will be used. Things are > just a whole lot easier if everything is encapsulated in a single EPR, > and more specifically in the wsa:Address field. Which is exactly how > WS-Addr anon works today. > Hmm, back to the conflation. I can't see anything in the WS-Addr spec > that prevents use of ref params, metadata or extensibility elements > within an anon EPR. Here, you want to use the special value of > [address], and put an application-defined type/value in the rest of > the EPR. That would fit your requirement to "keep it in the EPR". > I don't think loosening the wording makes thing indeterminate - it > still require