Re: RPCTF: Issues 16 and 78

Frank,

I like the new wording, in particular it makes it clear that the body of
an RPC response message must always contain a RPC response element but
that the element itself may be empty. Previous formulations might have
been taken to suggest that the SOAP body could be empty.

As for boxcarring, IMHO don't think this is something we need to support
in the core protocol. If people need to add boxcarring then they can do
so either using a custom header extension of by defining a new encoding
format for the body.

So in summary I am in favour of <FranksVersion2OfRPCTerms/> and
<FranksVersion5OfSection71/>.

Regards,
Marc.

Frank DeRose wrote:
> 
> Chris,
> 
> I think your rewording is a definite improvement. Actually, I think we need
> to tighten up the terminology even more.
> 
> Here is a proposal for adding RPC terms to the glossary so that they can be
> used unambiguously in Section 7 (see [1] for an earlier version of this
> proposal).
> 
> [Please forgive my seemingly pretentious use of elements like
> <FranksVersion2OfRPCTerms>. I'm trying to make it possible for us to refer
> to proposed rewrites unambiguously.]
> 
> <FranksVersion2OfRPCTerms>
> RPC message: a SOAP message (SOAP Envelope) containing an RPC request
> element, an RPC response element, or a fault element in its Body.
> 
> RPC request message: a SOAP message (SOAP Envelope) containing an RPC
> request element in its Body.
> 
> RPC request element: inside the Body of an RPC request message the
> serialization root that represents the [in] part of the RPC.
> 
> RPC response message: a SOAP message (SOAP envelope) containing an RPC
> response element or fault element in its Body.
> 
> RPC response element: inside the Body of an RPC response message the
> serialization root that represents the [out] part of the RPC or the fault
> generated by the RPC.
> </FranksVersion2OfRPCTerms>
> 
> Note that these definitions would need to be rewritten if we decide to allow
> boxcarring (see below).
> 
> Below are my most current attempts at rewriting the last paragraph of
> Section 7.1. <FranksVersion5OfSection71> prohibits boxcarring.
> <FranksVersion6OfSection71> allows boxcarring. For more discussion (and
> earlier versions) of these two alternatives see [2].
> 
> <FranksVersion5OfSection71>
> The Body of an RPC message MUST contain one and only one serialization root.
> In the case of an RPC request message, this root is the RPC request element.
> In the case of an RPC response message, this root is EITHER an RPC response
> element OR a fault element.
> 
> In the case of an RPC with a void return type and no [out] or [in,out]
> parameters, the RPC response element MUST be empty.
> </FranksVersion5OfSection71>
> 
> <FranksVersion6OfSection71>
> The Body of an RPC message MUST contain one serialization root and MAY
> contain more. In the case of an RPC request message, each root is an RPC
> request element. In the case of an RPC response message, each root is EITHER
> an RPC response element OR a
> fault element.
> 
> In the case of an RPC with a void return type and no [out] or [in,out]
> parameters, the RPC response element MUST be empty.
> </FranksVersion6OfSection71>
> 

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740

Received on Wednesday, 25 July 2001 05:32:23 UTC