RE: Proposal for issue 170: referencing missing data

 Stuart,
 I see now, I never actually read the whole RFC 2116 and I took 
the imperatives as "use where appropriate". 
 In this case, I think many MUSTs should be changed to SHOULDs in 
our spec.
 I disagree with MAY instead of SHOULD for faulting on broken 
references because it seems to indicate that broken references 
are perfectly legal but MAY be unsupported in which case the 
implementation would fault. I don't think broken references are 
perfectly legal, does anyone? 8-)
 Best regards and thanks for the enlightening quote below,

                   Jacek Kopecky

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



On Mon, 21 Jan 2002, Williams, Stuart wrote:

 > Hi Jacek,
 > 
 > >From RFC 2116 [1] which we cite as a *normative* reference:
 > 
 > <quote>
 > 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
 >    interoperability.
 > 
 > </quote>
 > 
 > 
 > Regards
 > 
 > Stuart
 > 
 > [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
 > what
 > >  > impact the generation of a Fault is intended to have.
 > >  > 
 > >  > The problem I have with MUST applied to the generation of faults (and
 > this
 > >  > is broader than just MissingID faults) MUST should be reserved for
 > things
 > >  > that give rise to interoperability problems. If someone goes against a
 > MUST
 > >  > 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
 > intermediaries)
 > >  > 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
 > to
 > >  > SHOULD or MAY.
 > >  > 
 > >  > I think that we can ask that question with respect to all cases of
 > fault
 > >  > generation that we specify.
 > >  > 
 > >  > I hope this response at least explains why I am reluctant about MUST...
 > I'd
 > >  > like to understand what the interoperability concern is if MUST were
 > relaxed
 > >  > to SHOULD or MAY.
 > >  > 
 > >  > Regards
 > >  > 
 > >  > Stuart
 >

Received on Monday, 21 January 2002 09:21:30 UTC