W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

RE: Stateless comms in the WSA

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Tue, 6 Aug 2002 13:49:55 -0700
Message-ID: <C513FB68F8200244B570543EF3FC653708AE35EE@MAIL1.stc.com>
To: "'Cutler, Roger (RogerCutler)'" <RogerCutler@ChevronTexaco.com>, www-ws-arch@w3.org

Well, first we should clarify which PSVI contributions we are talking about.
If we are talking about type information, we cannot of course ignore it in
situations like a WSDL with style=rpc and use=literal, where it's exactly
the type information coming from the schema that guides the
marshaling/unmarshaling for a specific programming language.

For what concerns the use of default/fixed attribute values, there are
various options to consider:
- rule out their use within the schema (all attributes over the wire have
necessarily specified values)
- allow the use of default/fixed, but require that the sender use the schema
to fill out the missing information (same as previous case as long as the
wire is concerned - this would only allow a subset of all the legitimate XML
infosets associated with that schema to go over the wire).
- allow any XML infoset compatible with the specified schema to go over the
wire (the receiver has to add any missing information using the schema -
this is the issue initially brought up on the Security Question thread).


-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Tuesday, August 06, 2002 1:21 PM
To: 'Mark Baker'; Champion, Mike
Cc: www-ws-arch@w3.org
Subject: RE: Stateless comms in the WSA

I would be quite unhappy with "MUST NOT" in this context, although I agree
with the general sentiment of discouraging this sort of thing.

It seems to me that we can make significant progress by staying with the
SHOULD's.  It appears to me that this is more consistent with what I see
coming out of the TAG than a lot of MUST's.

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Tuesday, August 06, 2002 2:09 PM
To: Champion, Mike
Cc: www-ws-arch@w3.org
Subject: Stateless comms in the WSA

On Tue, Aug 06, 2002 at 01:44:51PM -0400, Champion, Mike wrote:
> This is a very useful thread.  Picking up on Hal's point, I'd like to 
> see specific suggestions for what the WSA document should say about 
> this issue.
> - What section should it be in?  Some sort of "General principles of 
> using XML in web services payloads maybe?"  Then we can talk about 
> SOAP's philosophy about DTDs and PIs, this general point about 
> potential security threats from the actions that schema processors 
> could perform?  We might also mention in this section that it is not 
> possible to use W3C DTDs or Schemas to fully validate an XML message 
> against the SOAP 1.1 or 1.2 specs because there is no way to disallow 
> processing instructions, Doctype references or DTD internal subsets 
> via any current schema language.
> - What is the implication for the architecture itself?  I'm not sure 
> ...does anyone think that this needs to be in the domain of any future 
> working group?

Oh yes, most definitely.  Stateless communication is a key architectural
constraint of the Web, and I've also heard many Web services people talk
about its value too.

> - What's the implication for Best Practice?  My personal, humble opinion
> something like "One MAY use W3C XML Schemas for validating the payload
> a web services message, but one SHOULD NOT rely on anything in the 
> PSVI that is not in the raw InfoSet representation."

I'd say "MUST NOT", since to do so creates interoperability problems (or if
we're giving direction to spec authors, 'SHOULD use "MUST NOT"' 8-).  Also,
we should try to generalize it and use the PSVI, external entities, etc.  as
examples.  There are other ways of doing the wrong thing here, and they're
not all obvious.

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Tuesday, 6 August 2002 16:50:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:58 UTC