RE: LC5 Discussion (source endpoint utility, potential directions)

Glen, 

Here is a use case for keeping source endpoint as a MAP. When a destination
endpoint is busy, the intermediary would need to send the source endpoint
(original service requestor) a "wait" or a "try again" message. This message
may not be appropriate for the reply-to or fault-to addressee. I believe
this use case may also be true in a scenario without an intermediary. 

As for adding semantics to this property, I agree with your suggestion with
a slight change. IMHO, the pecking order for replies and faults should be
reply-to, fault-to respectively or alternatively "from". 

Thanks 

Vikas


-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Glen Daniels
Sent: Monday, May 16, 2005 12:43 PM
To: public-ws-addressing@w3.org
Subject: LC5 Discussion (source endpoint utility, potential directions)


Hi folks:

I took an action at the F2F to start some further discussion on the list
re: last call issue #5 [1], and make a proposal if possible.

The issue, if you'll recall, is about the utility (or not) of the
[source endpoint] property and associated <wsa:From> header.  We don't
currently say anything at all about how this can be used, and therefore
it's not a particularly testable feature.  There appeared to be three
(fairly evenly divided) camps:

1) Get rid of it (i.e. mark it "at risk")
2) Define some semantics for it
3) Leave it alone (it's a useful placeholder for whatever you want to do
with it)

We clearly couldn't come up with a strong consensus at the meeting to
either mark this feature "at risk", leave it alone, or redefine the
processing rules to give it some semantics.  Therefore, more email
discussion is warranted, hence this message.  Let me say off the bat
that I don't like choice (3) above, so I'm not going to consider that.
This is not to say others shouldn't argue for it if they believe it's
the right thing, but I think (1) or (2) are the real choices, since if
we want to leave it undefined we could just remove it and let someone
else define it themselves.  That said....

If there are really good use cases for this kind of thing, I would
propose that we go ahead and incorporate the [source endpoint] in the
defaulting rules for replies and faults (for instance, faults - if no
FaultTo, use ReplyTo; if no ReplyTo, use From).  However, I think this
hinges on their being good use cases, so I would suggest we continue the
discussion by detailing those.  I believe Anish and a couple of others
had some in mind (NAT?  Auditing?)... are folks willing to briefly write
them up?  If we cannot agree on good use cases, I think we should go
ahead and mark it "at risk" and attempt to remove it.

Thoughts / comments appreciated.  Let's figure this puppy out and close
it.

Thanks,
--Glen

[1] http://www.w3.org/2002/ws/addr/lc-issues/#lc5

Received on Wednesday, 18 May 2005 21:14:58 UTC