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

David,

This is not a transport level issue. The transport is able to deliver the
message to a service, but the service is busy. 

Adding more flavor to this use case, lets say we are doing RM, then the
destination RM endpoint received the message i.e. the transport has done its
job and destination RM endpoint sends back an acknowledgement to the
reply-to (which is probably the source RM endpoint). But the service which
is to process this message is busy. Then it would need to send the reply to
based on From header in the SOAP message. 

Vikas


-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, May 18, 2005 2:18 PM
To: public-ws-addressing@w3.org
Cc: public-ws-addressing@w3.org
Subject: 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:37:14 UTC