IRC log of ws-addr on 2006-10-02

Timestamps are in UTC.

19:58:48 [RRSAgent]
RRSAgent has joined #ws-addr
19:58:48 [RRSAgent]
logging to
19:59:05 [bob]
zakim, this will be ws_addrwg
19:59:05 [Zakim]
ok, bob, I see WS_AddrWG()4:00PM already started
19:59:27 [bob]
meeting: Web Services Addressing WG Teleconference
19:59:49 [bob]
Chair: Bob Freund
19:59:59 [gpilz]
gpilz has joined #ws-addr
20:00:30 [Jonathan]
Jonathan has joined #ws-addr
20:01:13 [MrGoodner]
MrGoodner has joined #ws-addr
20:01:14 [bob]
20:01:45 [bob]
zakim, who is here?
20:01:45 [Zakim]
On the phone I see no one
20:01:47 [Zakim]
On IRC I see MrGoodner, Jonathan, gpilz, RRSAgent, Zakim, Katy, bob, prasad, plh, TonyR
20:01:56 [dorchard]
dorchard has joined #ws-addr
20:02:07 [anish]
anish has joined #ws-addr
20:02:35 [Jonathan]
Jonathan has joined #ws-addr
20:02:39 [bob]
zakim, who is here?
20:02:39 [Zakim]
On the phone I see no one
20:02:40 [Zakim]
On IRC I see Jonathan, anish, dorchard, MrGoodner, gpilz, RRSAgent, Zakim, Katy, bob, prasad, plh, TonyR
20:02:57 [TonyR]
zakim,who is on the phone?
20:02:57 [Zakim]
On the phone I see no one
20:03:04 [TonyR]
zakim, where am i?
20:03:04 [Zakim]
I don't understand your question, TonyR.
20:03:17 [TonyR]
zakim, what is the code?
20:03:17 [Zakim]
the conference code is 2337 (tel:+1.617.761.6200), TonyR
20:03:34 [pauld]
pauld has joined #ws-addr
20:03:44 [TonyR]
zakim, this is addr
20:03:44 [Zakim]
TonyR, this was already WS_AddrWG()4:00PM
20:03:45 [Zakim]
ok, TonyR; that matches WS_AddrWG()4:00PM
20:04:19 [plh]
20:04:30 [pauld]
zakim, bup-bump is me
20:04:30 [Zakim]
sorry, pauld, I do not recognize a party named 'bup-bump'
20:05:34 [Joanthan]
Joanthan has joined #ws-addr
20:05:41 [pauld]
zakim, who is making noise?
20:05:52 [Zakim]
pauld, listening for 10 seconds I heard sound from the following: ??P4 (24%), ??P5 (47%), ??P9 (9%), ??P14 (39%)
20:06:19 [pauld]
zakim, who is on the phone?
20:06:19 [Zakim]
On the phone I see no one
20:07:47 [Marsh]
Marsh has joined #ws-addr
20:08:06 [Paco]
Paco has joined #ws-addr
20:09:29 [plh]
scribe: plh
20:09:39 [plh]
20:09:41 [PaulKnight]
PaulKnight has joined #ws-addr
20:09:45 [plh]
Chair: Bob
20:09:56 [plh]
Meeting: Web Services Addressing
20:10:38 [plh]
Topic: Action items
20:10:50 [plh]
2006-08-21: cr31 - Tony Rogers to implement CHANGE 1&2 to the table in
20:10:50 [plh]
preparation for CR-31 PENDING
20:10:53 [pauld]
revised table from TonyR:
20:11:20 [plh]
Tony: need more input from the Working Group
20:12:13 [pauld]
Paco and Anish outlined proposal for cr33:
20:12:17 [plh]
Bob: Anish and Bob action item is on today's agenda. I propose that we take some steps back
20:13:18 [plh]
Topic: previous minutes
20:13:33 [plh]
Previous minutes:
20:13:37 [anish]
20:13:42 [plh]
RESOLUTION: Previous minutes approved
20:14:01 [bob]
ack anish
20:14:12 [plh]
Anish: our proposal is more an outline than a full proposal
20:14:41 [plh]
Topic: Time to reflect on what problem we are trying to solve wrt cr33
20:14:44 [TRutt_]
TRutt_ has joined #ws-addr
20:16:03 [plh]
Bob: looking back at the origin of the issue in Addressing and WS-RX, [..]. It seems that WS-RX is looking at establishing some form of unique endpoint identification, or transmitting parameters from one endpoint to the others.
20:16:25 [plh]
... wanted to know where folks want to focus their energy
20:17:51 [dorchard]
20:18:27 [plh]
Jonathan: we gave a destination property (uri, none, anonymous). Lots of place were you give a union of user defined values. Don't think our design is really broken, but others didn't allow others that to redefine their values. Can we recognize that none and anonymous are special values for this version.
20:18:37 [plh]
... ie don't use it as extensibility points
20:19:03 [anish]
20:19:03 [plh]
... I'm tempted to ask for an erratum for extensibility
20:19:07 [plh]
ack do
20:20:22 [TRutt_]
20:20:34 [plh]
David: architectural issue: address vs identifier. We tried to get away by only using addresses, but people are trying to give identifiers effect to them. Reference properties were architectured around that.
20:20:55 [plh]
... "use the back channel since there is no address, but there is an identifier"
20:21:04 [bob]
ack anish
20:21:29 [plh]
Anish: Jonathan, are you thinking asking for isAnon?
20:22:23 [plh]
Jonathan: no, but we say that only none and anonymous are special
20:22:59 [plh]
Anish: we have abstracted the thing so much that it's really unclear how things work. Anonymous URI doesn't mean much in the Core.
20:23:45 [plh]
... people want to change where the response goes and we haven't give the ability to do so.
20:23:54 [GlenD]
GlenD has joined #ws-addr
20:24:07 [GlenD]
+1 to Anish's points
20:24:21 [GlenD]
also, apologies for showing up late
20:24:29 [plh]
... ws-rx realized that the soap binding isn't very useful as-is.
20:24:34 [bob]
ack tr
20:24:53 [GlenD]
20:25:16 [Paco]
20:25:18 [plh]
Tom: we got rid of ref props because they affected dispatch. The WS-RX committee needs to investigate if using a ref param would work.
20:25:33 [GlenD]
20:25:50 [anish]
20:25:55 [plh]
... rewording the document might be useful. +1 to Jonathan: the only special URIs are the one we define.
20:25:57 [bob]
ack paco
20:26:41 [TRutt_]
Ref Properties were taken out since they effected the "dispatch" of where a message would be "delivered" on the receiving end, Ref parms do not affect "dispatch" but do provide additional information for intermediaries and the ultimate destination, WS-RX TC needs to consider if a queueId in an epr with wsa:anon address could work
20:27:27 [plh]
Paco: The anonymous marker was badly designed. It is restrictive. That seems a shortsighted approach. We have to plan for composability.
20:28:00 [GlenD]
20:28:03 [plh]
... from my point of view, it does make to look at a better semantic.
20:28:09 [GlenD]
q+ Marc
20:28:14 [plh]
ack an
20:28:17 [bob]
q+ march
20:28:24 [plh]
q- march
20:29:20 [plh]
Anish: two ways to move forward: redesign anonymous using policy or no change anything and ask WS-RX to work around that (ie use ref params).
20:30:48 [plh]
Bob: when we had the discussion about the meaning of anonymous, we used it as an identifier for the backchannel resource. Here folks would like to pass some additional information beyond it.
20:31:04 [TRutt_]
s/a queueid/a ref Parm with queueid/
20:31:19 [plh]
ack glen
20:31:34 [pauld]
20:31:44 [MrGoodner]
q+ Jonathan
20:31:56 [anish]
q+ to comment on bob's comment
20:32:36 [anish]
20:32:53 [plh]
Glen: I do think that people are using ref params to identify sub-resource beyond the endpoint. That's reasonable. Here, there is a thing that is meant when you send a ReplyTo URI. We polluted that space by adding special values.
20:33:48 [plh]
... there is no way to mark that a URI is special.
20:33:50 [anish]
... and they are special in the same way (back channel)
20:34:17 [plh]
... a solution could have been not include anything in the reply
20:34:17 [bob]
ack marc
20:35:18 [plh]
Marc: the distinction between ref props and ref params is a distraction, since there's the same for the receiver. RM is overloading ReplyTo.
20:35:29 [anish]
20:35:36 [bob]
ack jonath
20:35:37 [Katy]
20:35:44 [plh]
... the URI for anonymous is well-defined.
20:36:44 [bob]
ack anish
20:36:51 [TonyR]
20:36:52 [plh]
Jonathan: addressing and identification is still confusing here. RM doesn't make use of the addressing functionality.
20:36:57 [TRutt_]
20:37:42 [plh]
Anish: MakeConnection is about ... making a connection and you don't have a choice to redirect it somewhere else. That's the reason why ReplyTo is ignored.
20:38:48 [TRutt_]
Focusing on WS-addressing, we have a statement that other specs can define their own "anonymous" like urii, with the wsdl binding not providing markers to state their use
20:39:17 [plh]
Anish: the fact that MakeConnection is one-way and still use the backchannel is a common pattern in RM.
20:40:22 [plh]
... the problem is about wsaw:Anonymous. Do we want to mean something specific about our anonymous URI, or to use the backchannel?
20:40:24 [GlenD]
Anish - excellent way to frame that. Thanks.
20:40:27 [bob]
ack katy
20:41:07 [mlittle]
mlittle has joined #ws-addr
20:41:19 [bob]
ack tonyr
20:41:35 [plh]
Katy: the replyTo semantic is defining by our spec. Here we're saying that others can define their own semantic. In an ideal world, RM should ahve defiend their own URI
20:41:39 [GlenD]
q+ DaveO
20:41:56 [TRutt_]
5.2.1 states "Note that other specifications MAY define special URIs that have other behaviors (similar to the anonymous URI)."
20:42:17 [plh]
Tony: it was suggested in RM that they use the from header to identify who they are.
20:42:28 [pauld_]
pauld_ has joined #ws-addr
20:42:36 [bob]
ack tru
20:42:43 [Katy]
In an ideal world RM should have defined their own 'replyTo' for RM semantics (not URI as minuted)
20:42:52 [TonyR]
s/in RM//
20:43:18 [plh]
Tom: we have a problem in our spec in 5.2.1. They took a statement to heart and the WSDL binding doesn't enable their use.
20:43:19 [pauld_]
pauld_ has joined #ws-addr
20:43:37 [pauld_]
pauld_ has left #ws-addr
20:43:43 [Jonathan2]
Jonathan2 has joined #ws-addr
20:44:00 [pauld_]
pauld_ has joined #ws-addr
20:44:04 [anish]
20:44:37 [Jonathan2]
FWIW, the statement Tom quotes is the one I'm tempted to delete through errata.
20:45:27 [plh]
Anish: you don't have the value in the from present in the response message.
20:46:21 [plh]
... [explains WS-RM]
20:47:22 [plh]
Bob: they're making use of the from as a hack as well.
20:47:27 [plh]
20:47:35 [plh]
ack dave
20:47:40 [bob]
ack dave
20:48:30 [MrGoodner]
20:48:40 [Paco]
20:48:59 [plh]
David: Folks are trying to use WS-Addressing and they are finding some issues. It's important to think about this. WS-Addr is intended to be a Core spec. We should allow them to build what they want to do.
20:49:10 [plh]
... I'm not a big fan of ignoring it
20:49:29 [plh]
... we should try to address their use cases
20:50:35 [plh]
... re distinction between ref props/ref params was meant for identification. We prevented people from using EPR as identifiers.
20:50:39 [TRutt_]
20:50:58 [Katy]
I agree with Dave's comments about WS-A should provide building blocks (although it conflicts with my previous comment about separate rm replyTo) :o)
20:52:27 [plh]
David: the other idea was to bring some other kind of identifying information, licensed to be used for EPR comparisons.
20:52:55 [bob]
ack anish
20:53:08 [TRutt_]
Ref Parms, while not a part of identity used fo dispatching the message to the ultimate destination, they are data that the desitnation can use as part of its processing, In fact ws-rf has a way to use ref_parms to "select" an underlying resource at that endpoint for its querry operations.
20:53:47 [plh]
Anish: cr33 is about wsaw:Anonymous and WS_Rm might have to change their spec. So should it about the two URIs we define or aobut the backchannel?
20:54:15 [plh]
Tom: until recently, people thought that backchannel and anonymous were the same thing.
20:54:36 [bob]
ack mrg
20:55:34 [mlittle]
mlittle has joined #ws-addr
20:55:43 [mlittle]
20:55:45 [bob]
ack paco
20:55:54 [plh]
MarcG: Transaction does not have issues with WS-Addressing. Ditto for SecureConversation and WS-Trust. Seems like the Core problem is only coming from WS-RM, and on extensibility points added at their request
20:56:21 [pauld]
a brick is a brick is a brick
20:56:30 [TRutt_]
s/people/some people/
20:56:39 [plh]
Paco: WS-Addressing didn't really define how the semantics apply to the protocol.
20:56:42 [mlittle]
Speaking as one of the editors of WS-TX, I agree. We've not had any problems with wsa.
20:57:23 [MrGoodner]
Thanks, I'm an editor in SX and can't think of any problems with SC or Trust either
20:58:09 [plh]
Paco: if we want to have a useful marker, we better focus on the backchannel
20:58:19 [mlittle]
To be honest, we thought the wsa text was pretty clear about what can and can't be done. Very few ambiguities, which for a standard is compliment ;-)
20:58:30 [TRutt_]
In the use case of WS-RF, the Ref Parm presence in a request can have an effect on the semantics of the response to that message (e.g., used as a sub resource selector on a get state request)
20:58:44 [bob]
ack tru
20:58:47 [plh]
Tom: In the use case of WS-RF, the Ref Parm presence in a request can have an effect on the semantics of the response to that message (e.g., used as a sub resource selector on a get state request)
20:59:34 [plh]
20:59:51 [MrGoodner]
he did mean RF
20:59:59 [MrGoodner]
RF = ResourceFramework
21:00:01 [plh]
21:00:15 [MrGoodner]
21:00:20 [bob]
21:01:14 [plh]
Bob: we could go in and add ref props. We could change the way we restrict ref params so that people will use them.
21:02:01 [plh]
... we could suggest that they use their own replyTo. Or come up with new attr/elts for identification purpose.
21:02:21 [plh]
... Or clarify the meaning of wsaw:Anonymous
21:02:39 [plh]
... setting aside the WSDL marker discussion ...
21:02:49 [anish]
21:03:11 [anish]
21:03:17 [plh]
... the specific use case is "attempt to provide some identifying information while expecting a response from something"
21:04:12 [plh]
... is there anyway we can do this in a normative way in our specification?
21:04:31 [anish]
21:04:46 [mlittle]
21:05:04 [Jonathan2]
Not sure what you're saying Bob, but it sounds scary!
21:05:09 [plh]
Paco: we explicitly decided to stay out of the identification business. that would be a big change of direction...
21:05:11 [gpilz]
21:05:21 [pauld]
21:05:56 [plh]
Paco: re opaque. you don't want to build a dependency onto a particular structure.
21:06:18 [plh]
Anish: I interpreted opaque to mean opaque to anybody but the minter.
21:06:43 [plh]
... all those options are about changing Core or SOAP binding. Is that correct?
21:06:48 [plh]
Bob: not entirely sure yet
21:07:52 [plh]
... want to make sure that everyone understands why the RM folks arrived there, ie to put some identification into a form of anonymous URI. We have plenty of fields for that but we don't say what they mean.
21:08:17 [bob]
ack ani
21:08:18 [plh]
ack anish
21:08:25 [bob]
ack gpil
21:09:20 [TRutt_]
21:09:23 [plh]
Gil: I can basically use ref params and no worry about unintended side effects.
21:10:30 [plh]
... we're missing one of the constraints from the design of RM. They tried not to pervert common WS-A implementations. That's why they're not using from. From doesn't get reflected back in the headers of the reply message.
21:10:54 [plh]
Bob: TX spits it back as a To
21:11:28 [plh]
Gil: RM didn't want to change implementations.
21:11:31 [anish]
that would mean that TX does not use replyTo and instead uses From
21:12:17 [plh]
Anish: seems like TX uses from to identify the sender, ie they don't use replyTo. Then the requirements for TX is a little different.
21:12:47 [mlittle]
TX defined that all messages patterns are really one-ways. There are responses, but they are application level messages.
21:12:56 [mlittle]
21:13:27 [TRutt_]
I agree with Bob that a key thing that WS-RX TC did to their wsrm:anon URI is to combine queueIdentity info in a "anonymous" address.
21:13:29 [plh]
21:13:44 [mlittle]
There are probably 1 or 2 places in the entire WS-TX specification where ReplyTo makes sense: those interactions are request-response.
21:13:52 [bob]
21:13:56 [plh]
Anish: from an RX point of view, they can't do this. they're trying to make request/response MEP reliable
21:14:42 [mlittle]
How backwardly compatible with existing implementations do we have to be? It's laudable that RX wants to work with existing implementations, but if that means we have to hack wsa, is that right?
21:15:30 [bob]
ack pauld
21:15:58 [Jonathan2]
21:16:04 [Jonathan2]
21:16:09 [MrGoodner]
21:16:32 [mlittle]
21:16:36 [anish]
mark, the problem is not compatiblility with existing implementations, but that whatever is specified in wsa:From MUST be included in the response message. It is certainly possible for ws-rx to make that a requirement. But that is not how they went. Without the contents of wsa:From in the response message, it is not possible to do what wsrx wants to do
21:16:38 [plh]
Paul: we shipped our Core and SOAP. I'm not hearing that we're broken.
21:16:44 [bob]
ack tr
21:17:29 [anish]
... so wsrx will have to specify where info in the wsa:From header is included in the response message (perhaps as a new soap header)
21:18:09 [bob]
ack mrg
21:18:12 [plh]
Tom: the key issue is to put identification on anonymous URIs.
21:18:43 [mlittle]
Anish, ok so they should change and use wsa:From ;-)
21:19:22 [anish]
mark, ... and define a new SOAP header that will be present in the response message?
21:19:31 [plh]
MarcG: the RM are trying to initiate the response/request pattern.
21:19:51 [TRutt_]
I do not think the wsa group should try to be the wsrx group
21:19:59 [plh]
Bob: do we agree that the problem is about the need of transfer identifying information?
21:20:30 [plh]
Jonathan: that may be the problem, but I saw other solutions who were able to do RM without this.
21:20:43 [plh]
... (see PAOS)
21:20:43 [anish]
q+ to say that PAOS does not work
21:21:10 [bob]
ack anis
21:21:10 [Zakim]
anish, you wanted to say that PAOS does not work
21:22:43 [pauld]
notes we have messageIds andan extensible relatesTo to provide correlation
21:23:22 [plh]
Jonathan: would like to see a model for the polling behavior used by RM
21:23:25 [pauld]
s/andan/and an/
21:23:51 [TRutt_]
21:24:02 [bob]
ack tr
21:24:20 [plh]
Tom: if we agree that you shouldn't put identification in the anonymous URI, we might want to change 5.2.1.
21:24:28 [Jonathan2]
+1 of course ;-)
21:24:54 [plh]
Bob: do we think that folks should be allowed to put identification information in the anonymous URI?
21:25:24 [plh]
Anish: meaning the ws-addressing uri?
21:25:32 [plh]
Tom: in 5.2.1
21:26:52 [plh]
Bob: right now, they're trying to use their own URI to indicate the use of the backchannel?
21:28:03 [plh]
Katy: the answer to that question might depend on whether we provide alternative solutions
21:28:08 [TRutt_]
21:28:16 [gpilz]
21:28:25 [plh]
... without any, we would want to allow identifying info in anon URI
21:28:28 [bob]
ack tr
21:29:07 [plh]
Tom: we should on the long term here. If we told they couldn't this, that will force them to do something else.
21:29:16 [bob]
ack gpil
21:29:48 [plh]
Gil: I think we're asking the wrong question: How deeply into this identifying thing do we want to get?
21:30:24 [plh]
... addressing URI represents addressing and backchannel
21:30:34 [plh]
... should we separate those two?
21:30:46 [Paco]
21:31:40 [plh]
Bob: if we stay out of the identity business, should we provide alternative ways? The specific resource that anon URI identifies is backchannel.
21:32:04 [plh]
... but we didn't say anything about the general URI
21:32:11 [bob]
ack paco
21:32:39 [plh]
Paco: many reason to stay away from identity business. It makes sense to try to use URIs for that effect.
21:33:08 [gpilz]
21:33:34 [bob]
ack gpil
21:33:36 [plh]
... I don't see much value in creating a template
21:35:13 [Paco]
21:36:02 [bob]
ack paco
21:36:43 [TRutt_]
Tony hit it: they are trying to extend to back channel to allow responses from earlier requests!
21:37:12 [gpilz]
21:37:20 [bob]
ack gil
21:37:32 [TRutt_]
And since they are doing that they need to include some data to control which earier request can flow on the backchannel to the make connection request
21:37:51 [MrGoodner]
they are also trying to enable initiating new requests as the response to the make connection request
21:38:04 [plh]
Gil: they created a template for anon URIs and they're asking us to recognize it as the anon URI.
21:38:06 [TRutt_]
21:38:21 [bob]
ack gpi
21:38:34 [GlenD]
That concept doesn't actually make sense unless you understand RM anyway, right?
21:38:38 [MrGoodner]
enabling the responses to previous requests works without the need for the RM anon URI
21:38:39 [bob]
ack tr
21:38:50 [MrGoodner]
21:39:03 [plh]
Tom: they're trying to use the backchannel for earlier requests.
21:39:10 [bob]
ack mrg
21:39:55 [plh]
MarcG: RM anon URI was added as an alternative for initiating a new request
21:41:10 [plh]
Bob: so is Anon URI with identifying information legal? Is there an error with trying to generate your own version of Anon?
21:41:21 [plh]
... should we solve this?
21:41:31 [GlenD]
21:41:41 [TonyR]
21:41:53 [plh]
MarcH: you can always use a SOAP header!
21:42:22 [plh]
Katy: but that SOAP header wouldn't be pass back
21:42:34 [plh]
MarcH: you can say it has to be echoed.
21:43:01 [plh]
Tony: they want something that magically appears in the response
21:43:06 [gpilz]
21:43:07 [anish]
21:43:10 [pauld]
yeah, let them eat soap!
21:43:51 [TRutt_]
How about rubbing soap in their mouth:-)
21:43:54 [plh]
... they want to encode it on the message going back
21:44:13 [plh]
... ref params are opaque only at the WS-Addressing level
21:44:14 [bob]
ack tonyr
21:44:26 [bob]
ack glen
21:44:28 [plh]
... RM shouldn't have to consider them open
21:44:46 [plh]
Glen: the RM URI doesn't make sense to non-RM implementations
21:44:56 [anish]
21:45:52 [plh]
... the way we define anon is to make sure to connect the reply in a WSDL req/resp MEP to the request.
21:46:10 [TRutt_]
+1 to glen
21:46:25 [plh]
Bob: the MEP that they use is unique
21:46:27 [bob]
21:46:35 [bob]
ack gpil
21:47:20 [plh]
Gil: the idea of pushing RM into the addressing layer. RM source and RM destination are async in their behavior.
21:48:56 [Katy]
21:49:00 [plh]
... THE RMS is trying to reach the RMD as best as it can.
21:49:15 [bob]
ack katy
21:49:46 [gpilz]
the RMS and RMD are asymmetric in their behavior
21:50:05 [TRutt_]
21:50:13 [plh]
21:50:18 [TonyR]
21:50:20 [bob]
ack tr
21:50:43 [anish]
21:50:56 [gpilz]
one of the major drivers behind the WS-RM anon URI was the urge to allow WS-RM implementations to remain unaffected by the fact that the RMD is resident in a non-addressable entity
21:51:14 [bob]
ack tony
21:52:25 [MrGoodner1]
MrGoodner1 has joined #ws-addr
21:52:33 [plh]
Tony: RM wants something that is already being sent back. They want to pass the identifier with minimal effort
21:53:11 [plh]
... they really need to operate as a separate layer on top of addressing.
21:53:34 [gpilz]
21:53:38 [gpilz]
21:54:01 [plh]
.. expecting the state of RM to be passed around in the addressing URI seems wrong.
21:54:31 [bob]
ack ani
21:55:13 [pauld]
+1 I want to use Addressing without RX, but RX layers Addressing, so has to work within its constraints
21:55:26 [plh]
Anish: Marc suggestion to use SOAP headers wasn't considered. This is interesting feedback. Ref params has been considered at least. I'll get this back to WS-RM.
21:55:54 [plh]
Bob: is this proposal something we ought to consider as a WG response?
21:55:56 [bob]
21:56:11 [plh]
Tom: any formal thing would be counter productive move for the moment
21:56:13 [dorchard]
dorchard has joined #ws-addr
21:56:34 [plh]
Anish: I also need to think about this. We just didn't consider in WS_RX and needs to see if it really works for us
21:56:49 [plh]
Bob: ok not to send a formal response but we need to have the dialog open.
21:58:02 [plh]
Bob: I still didn't hear that we need to fix something?
21:58:21 [plh]
Tom: we never thought of anonymous address carrying identifying information
21:58:41 [plh]
Tony: I think the id should be carried an other way
21:59:35 [plh]
ACTION Bob: enumerate the alternatives for cr33
22:00:43 [plh]
22:00:56 [bob]
rrsagent, make logs public
22:01:02 [TonyR]
TonyR has left #ws-addr
22:01:06 [bob]
rrsagent, generate minutes
22:01:06 [RRSAgent]
I have made the request to generate bob
22:01:15 [plh]
zakim, bye
22:01:15 [Zakim]
Zakim has left #ws-addr
22:01:22 [TRutt_]
TRutt_ has left #ws-addr
22:01:22 [bob]
philippe, thanks for scribing
22:01:53 [plh]
welcome, I hope I didn't a bad job at it. the last 30 minutes were difficult.
22:02:05 [plh]
now I need a good rest
22:02:13 [plh]
(if it's ok to use this word :)
22:03:11 [bob]
take one and get well
22:03:37 [bob]
hodid the meeting help?
22:06:34 [bob]
bob has left #ws-addr