W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > October 2009

[Bug 7911] mismatching action and body wrapper

From: <bugzilla@wiggum.w3.org>
Date: Mon, 19 Oct 2009 21:45:17 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1N002X-0007qt-JH@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7911





--- Comment #6 from Doug Davis <dug@us.ibm.com>  2009-10-19 21:45:17 ---
> Our spec is not targeting those issues, but as I said before, we, in _this_
> spec says "value A should be in places X and Y", so apart from the classical
> error case where value is not really value A, or invalid, we have _introduced_
> the case where X and Y can have different value.

No we have not.  The spec is very clear that this MUST NOT happen.
If it does the sender has not adhered to the spec.  This is no different
than the following other uses of MUST (just a random sampling):
- - - - - - - - - - - - - 
All messages defined by this specification MUST be sent to a Web service that
is addressable by an EPR (see [WS-Addressing]). 

Unless otherwise noted, all IRIs are absolute IRIs and IRI comparison MUST be
performed according to [RFC 3987] section 5.3.1.

A compliant SOAP Node that implements a resource MUST provide the Get operation
as defined in this specification, and MAY provide the Put and Delete
operations. 

A Get request MUST be targeted at the resource whose representation is desired
as described in 2 Terminology and Notation of this specification.
- - - - - - - - - - - - - 


In each of these cases we don't say what MUST happen if the MUST is not
adhered to.  I would point out that this is true for lots of other specs 
(not just WS* specs), for example some from the HTTP spec:
- - - - - - - - - - - - - 
HTTP/1.1 recipients MUST accept such bad optional whitespace and
remove it before interpreting the field value or forwarding the
message downstream.

These special characters MUST be
in a quoted string to be used within a parameter value (as defined in
Section 3.3).

The proxy/gateway's response to that request MUST be
in the same major version as the request.
- - - - - - - - - - - - - 
In none of these cases does the spec say what is to happen if the MUST
is not adhered to.


> See above, we introduced a new class of error.

huh?  How?  The spec says what the XML on the wire MUST look like.
This is no different than requiring the client to adhere to the xsd
defined by a spec. 

I feel like there's something else behind this issue and I'm still
not seeing it - or you're not letting us in on the secret.


If you really want to head down this rat hole, then we need to do this 
for ALL MUSTs in ALL RA specs and not just cherry-pick one.  And where do you
draw the line?  Once you say what MUST happen during this faulting condition
you've now introduce yet another MUST and how will you recover from that
one?  Its going to be recursive.


My objection to this isn't just because it seems like a pointless exercise,
but one of a practical nature.  The path you're headed down is one
where you're going to require all endpoints to be compliance checkers.
They can no longer be forgiving in what they accept - they MUST 
verify all incoming messages and they MUST reject them if they don't
adhere to the spec in the slightest way.  This is a very dangerous and
expensive path to head down.

Imagine if all HTTP servers rejected ALL HTTP requests that were not 
100% perfect.  What percentage of the clients would suddenly stop working?
I suspect a lot of them.  Many people design their systems under the
"be liberal in what you accept" model - this issue will ban this.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
Received on Monday, 19 October 2009 21:45:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 19 October 2009 21:45:21 GMT