Special treatment for well-known endpoints

I wanted to pull together concisely some the main arguments I've been 
putting forth, lest they continue to get lost in the other discussion:

If all endpoints can be handled simply through SOAP extensibility, then 
ReplyTo and FaultTo can and should be handled this way.  This would make 
the core and soap specs smaller and make it clear to those trying to 
define other interactions that nothing special is going on.  Building 
request/reply/fault on top of a core that defines reply and fault 
endpoints explicitly says nothing at all about extensibility to other 
cases.  Building request/reply on top of a core that does not define 
reply and fault endpoints would say quite a bit about extensibility to 
other cases.

On the other hand, if some endpoints need special handling such as MAPs 
and SOAP properties -- as reply and fault appear to -- then other 
endpoints must be presumed to need the same handling, and "just use SOAP 
extensibility" is not a sufficient answer for endpoints other than reply 
and fault.  The direct way around this is to allow new endpoints to be 
treated in the core on the same basis as reply and fault.

In either case, reply and fault should not be accorded any special 
treatment, beyond pre-defining names for them in recognition of their 
(current) prevalence.

I've been concentrating on the second approach, but I'm not opposed to 
the first.

Received on Thursday, 17 March 2005 13:20:58 UTC