RE: Issue: Problem with ProcedureNotPresent fault subcode

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 05:25:06 UTC