W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

RE: Proposal for issue 170: referencing missing data

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 21 Jan 2002 14:13:24 -0000
Message-ID: <5E13A1874524D411A876006008CD059F1928CC@0-mail-1.hpl.hp.com>
To: "'Jacek Kopecky'" <jacek@systinet.com>
Cc: xml-dist-app@w3.org
Hi Jacek,

From RFC 2116 [1] which we cite as a *normative* reference:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for




[1] http://www.ietf.org/rfc/rfc2119.txt?number=2119

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: 21 January 2002 14:03
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: Proposal for issue 170: referencing missing data
>  Stuart,
>  when thinking about faulting, I don't think in terms of "does 
> not doing this break interop?" but in terms of "is this an error? 
> Always? Really, positively always?"
>  And if the answer to my version of the question is "yes, yes, 
> really, positively yes", I'd make generating a fault mandatory.
>  So since I think a broken link in SOAP Encoding graph indicates 
> an error, like, always, therefore I propose MUST. 
>  Let's please not loose again the context in which the MUST is 
> used - the words "when deserialization encounters a broken link" 
> which are meant to refrain from mandating checking when the data 
> is not in fact needed.
>  The spec is IMHO very deliberately talking about generating and 
> not reporting faults because SOAP is one-way in the core and only 
> MEPs can specify the reporting of generated faults. In some cases 
> the generated faults, even under MUST conditions, can be silently 
> dropped to a black hole by a conforming processor.
>  Best regards,
>                    Jacek Kopecky
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> On Mon, 21 Jan 2002, Williams, Stuart wrote:
>  > Hi Jacek,
>  > 
>  > >  There has been the question of what a SOAP fault is meant to 
>  > > induce. My experience is that although in some cases there may be 
>  > > ways to gracefully handle the situation, usually faults like 
>  > > MustUnderstand, DataEncodingUnknown etc. are just reported 
>  > > somewhere and the client quits. I think the same handling should 
>  > > be expected on a MissingID fault.
>  > 
>  > I guess I should respond to that since I at least and one  who asks
>  > impact the generation of a Fault is intended to have.
>  > 
>  > The problem I have with MUST applied to the generation of faults (and
>  > is broader than just MissingID faults) MUST should be reserved for
>  > that give rise to interoperability problems. If someone goes against a
>  > bad things happen. At present our language is very much around the
>  > generation of faults and we say little about the reporting of faults.
>  > 
>  > So my question is, if someone fails to generate a fault in a given
>  > circumstance, does that give rise to an interoperability problem? 
>  > 
>  > If the answer is YES, then MUST is appropriate. 
>  > 
>  > Bear in mind that in the case of a MissingID the senders (or
>  > conformance to the encoding style is already in doubt... what we're
>  > considering is the MUST on the generation of a MissingID fault.
>  > 
>  > If we are going to insist on MUST *generate* a fault, I would like to
>  > understand how interoperability would suffer if we were to relax MUST
>  > SHOULD or MAY.
>  > 
>  > I think that we can ask that question with respect to all cases of
>  > generation that we specify.
>  > 
>  > I hope this response at least explains why I am reluctant about MUST...
>  > like to understand what the interoperability concern is if MUST were
>  > to SHOULD or MAY.
>  > 
>  > Regards
>  > 
>  > Stuart
Received on Monday, 21 January 2002 09:13:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:45 UTC