Re: i0001: EPRs as identifiers (why XML?)

The SOAP binding should only be lossy for the Destination EPR. The
recipient  already has a concept of its own EPR, and thus shouldn't
need to reconstruct it from the message. If it didn't know its own
endpoint, how would it recieve the message in the first place?

EPR's that affect the destination of future messages (i.e.
ReplyTo/FaultTo) should escape the binding unscathed.

-steve
http://hyperthink.net/blog

On Wed, 17 Nov 2004 18:59:43 -0500, Mark Baker <mbaker@gmail.com> wrote:
> 
> The URI part of the EPR seems to fit well inside wsa:To, so I don't
> see a problem there.  What I believe is that the reference property
> information should be part of the URI, and therefore map to a SOAP
> envelope via wsa:To rather than an extension header.
> 
> BTW, partly as an aside (but partly not), I think it's quite telling
> that the SOAP binding is lossy (i.e. given a recipient of a SOAP
> message cannot reconstruct an EPR).  This suggests to me that
> insufficient thought has been put into the value of EPRs as a
> standalone entity.  Have any other bindings been defined?  I believe
> it is risky to draw any general conclusions about what an EPR should
> look like based on a single binding.
> 
> FWIW,  if reference properties were removed, then the binding would be lossless.
> 
> Mark.
> 
> 
> 
> On Wed, 17 Nov 2004 12:09:39 -0800, Jonathan Marsh <jmarsh@microsoft.com> wrote:
> >
> > To add to DaveO's response, remember the purpose of the sub-address.
> > It's used in conjunction with the address URI to enable the
> > infrastructure to deliver the message to its ultimate destination.  It's
> > designed to work with SOAP, which defines headers for the purpose of
> > delivering the message to the ultimate SOAP destination.  SOAP headers
> > are XML.  Thus it is quite natural for RefProps to be XML as well, to
> > eliminate a translation or binding process from some other form (plain
> > text?) to XML.  A model that wasn't SOAP-centric perhaps wouldn't get as
> > much synergy from XML.
> 
>

Received on Thursday, 18 November 2004 11:16:16 UTC