RE: Issues 368 and 369 Proposal

Henrik Frystyk  Nielsen writes:

> Would it be possible to qualify the MUST requirement on
> part 1 to indicate that one can implement, say, only a
> SOAP sender? That is, we state the intent in terms of
> "if you do X then you MUST do all required parts of X"?

I'm afraid I still have a serious problem with this.  It implies that all 
senders and receivers must in some sense be full function. 

We are NOT writing a specification for one or another packaged form of 
implementation, IMO.  We are specifying a protocol.  The rule for an 
implementation must be: be consistent with the specification, no more no 
less.  I'm sorry if that makes the QA folks wince, but there it is.

For example, let's say I claim to have an API (think DOM) that creates and 
writes out SOAP envelopes.  I claim our spec constrains that 
implementation, insofar as this implementation claims to write out 
"envelopes", and we give the rules for those.  Nonetheless, this 
implementation is neither a sender nor a receiver.  We do specify some 
specific responsibilities, such as sender, that an implementation can 
assume.  Still, we have no notion of completeness, except insofar as that 
follows from particular rules in the recommendation.  If I never send 
headers, that's fine, but if I do send them they must be as the Rec 
demands.  Similarly, a receiver that sends an mU fault for any message 
with an mU header targeted to that receiver is a perfectly legal and 
useful form of SOAP implementation -- some PERL scripts are doing this I 
believe.  It's just not a fully general purpose implementation.

These are serious distinctions and I am not willing to let them go, unless 
of course I've misunderstood something.  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Wednesday, 6 November 2002 14:03:24 UTC