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

Vikas Deolaliker wrote:

>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. 
>  
>
This seems more a transport-level concern, like an SMTP server
re-sending a message.  Or am I missing something?

>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:24:56 UTC