RE: Issue: Problem with ProcedureNotPresent fault subcode

 I've always viewed the RPC convention as an application of 
SOAP which specifies the contents of the body. Therefore I don't 
see an endpoint accepting both RPC and non-RPC messages. (An 
endpoint is an addressable part of a SOAP node.) Therefore my 
response is your (a). I see that this might need to be clarified 
in the spec.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Thu, 2 May 2002, Williams, Stuart wrote:

 > Hi Jacek,
 > 
 > I think Henrik has identified a deeper problem - basically how is a
 > recipient to know that the RPC conventions apply to a received message,
 > there being nothing explicit in the message indicated that this is the case.
 > 
 > Possible responses are:
 > 
 > a) The receiving end-point implicitly knows that that RPC conventions are in
 > operation - and the rpc:ProcedureNotPresent fault applies to any
 > unrecognised (first?) Body child.
 > 
 > b) To process the SOAP body a node must implicitly understand the semantics
 > of at least the first body child in which case use of the RPC convention
 > would be part of the semantics implied by the first body child - however...
 > in the case that the reciever does not 'understand' the first body child and
 > hence does not know that the RPC convention applies... I think Henrik is
 > correct that it cannot be expected to generate a rpc:ProcedureNotPresent
 > fault.
 > 
 > Relaxing the MUST to MAY or SHOULD does not address the deeper question, it
 > just takes a more relax'ed view about the imperative to generate a
 > particular fault. I find it a little disturbing that we have MUSTs that we
 > can relax so easily... again, on the basis that MUSTs should be being used
 > (by RFC 2119) to signify behaviours required for interoperability. *IF*
 > there are interoperability issues that critcially depend upon the generation
 > of such a fault, then then MUST should remain MUST and the issue of
 > recognising when the RPO convention is in operation should be addressed.
 > *IF* there are no critcial interoperability issues associated with the
 > generation of an rpc:ProcedureNotPresent fault, SHOULD or MAY is strong
 > enough (IMO).
 > 
 > regards
 > 
 > Stuart
 > --
 > 
 > > -----Original Message-----
 > > From: Jacek Kopecky [mailto:jacek@systinet.com]
 > > Sent: 02 May 2002 09:15
 > > To: xml-dist-app@w3.org
 > > Subject: Re: Issue: Problem with ProcedureNotPresent fault subcode
 > > 
 > > 
 > >  Again, I'd prefer SHOULD instead of MAY, because the latter 
 > > suggests that issuing a different fault in such a condition is 
 > > perfectly OK. 
 > >  Best regards,
 > > 
 > >                    Jacek Kopecky
 > > 
 > >                    Senior Architect, Systinet (formerly Idoox)
 > >                    http://www.systinet.com/
 > > 
 > > 
 > > 
 > > On Wed, 1 May 2002, Henrik Frystyk Nielsen wrote:
 > > 
 > >  > 
 > >  > Minor nit - in section 4.3 in part 2, it is stated that the
 > >  > "rpc:ProcedureNotPresent" Subcode MUST be used in the 
 > > following case:
 > >  > 
 > >  > 	A fault with a Value of "env:Sender" for Code and a
 > >  > 	Value of "rpc:ProcedureNotPresent" for Subcode MUST
 > >  > 	be generated when the receiver does not support the
 > >  > 	procedure or method specified.
 > >  > 
 > >  > However, there is nothing in the message that indicates that a SOAP
 > >  > message is following the RPC convention and nothing that 
 > > prevents the
 > >  > RPC convention from being used selectively in the SOAP 
 > > receiver (if at
 > >  > all). As a result it is not possible for the SOAP receiver to know
 > >  > whether a message is following the RPC convention or not 
 > > nor whether it
 > >  > should respond using this fault or not. In other words, 
 > > this requirement
 > >  > is not enforceable.
 > >  > 
 > >  > I would therefore suggest that we change it to a "MAY" so 
 > > that it says
 > >  > 
 > >  > 	A fault with a Value of "env:Sender" for Code and a
 > >  > 	Value of "rpc:ProcedureNotPresent" for Subcode MAY
 > >  > 	be generated when the receiver does not support the
 > >  > 	procedure or method specified.
 > >  > 
 > >  > Henrik Frystyk Nielsen
 > >  > mailto:henrikn@microsoft.com
 > >  > 
 > >  > [1] 
 > http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#rpcfaults
 >  > 
 >

Received on Thursday, 2 May 2002 07:05:40 UTC