W3C home > Mailing lists > Public > public-ws-addressing@w3.org > May 2005

LC5 Discussion (source endpoint utility, potential directions)

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Mon, 16 May 2005 15:43:24 -0400
Message-ID: <80A43FC052CE3949A327527DCD5D6B27010BCAD4@MAIL01.bedford.progress.com>
To: <public-ws-addressing@w3.org>

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


[1] http://www.w3.org/2002/ws/addr/lc-issues/#lc5
Received on Monday, 16 May 2005 20:13:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:09 UTC