Server side DTD validation only ?

[Murray Maloney]

The moral that I take from this exchange is:

DTD validation can be exclusively server-side if the client
has sufficient trust in the server, otherwise client-side 
validation is recommended.

Please note that certain applications will want to have servers
on both sides of an exchange, with the client communicating
with a local server that may or may not perform validation 
of its own. Thus, a client's trust in a server can be mitigated by 
the presence of an intermediary server that performs pre-validation
as a trusted service for the client.

For example, in a telephony application, any switch along the path
of a document exchange, from sender to recipient, can be responsible 
for validating along the way. So, the sender's server (a phone) might 
validate the message that it sends out, or it may restrict its messages
to a canned set of messages that conform to an industry standard. As
the message is received into the telephone network, and at any switch
along the way, a validation service is free to test any message --
rejecting/returning any message that is not valid. The client's telephone
service might have its own message processing service that checks 
incoming messages and performs functions on behalf of the client,
and it may choose to validate. Before transmitting a message to the
client, the telco's messaging service checks with the client and asks
whether it wants the server to validate on its behalf. And when the 
client gets the message, a local validation service might be available
for messages that have not been pre-validated -- for whatever reason.

At 08:50 AM 6/14/99 -0700, David Brownell wrote:
>"Roldan, Alex" wrote:
>> 
>> To me It seems that performing DTD validation on the client and server side
>> is an unnecessary overhead.   Currently, I am only performing validation
>> against the DTD on the server side app.  The request and the response are
>> both validated by the server app by pre-pending the DTD to the XML document
>> before it is validated.  The text XML data created by the client does not
>> contain the DTD or an external reference to the DTD.
>> 
>> 1.  Is this the right approach ?
>
>If you control both the client and server, and can keep them
>always in sync (e.g. you're downloading the client from that
>server) so that you don't run into versioning problems.
>
>From my perspective, both of those restrictions are atypical.
>
>Of course you also have to keep in mind that validation is
>only one level of error checking, and it's possible that the
>other levels will catch the problems that'd crop up.
>
>
>> 2.  What are the problems I can run into ?
>
>If you write clients for network programs, you learn that
>you must not trust servers to perform according to their
>specifications ... e.g. a server operated by a business
>competitor might very well attempt to subvert clients that
>are trusting.  It is routine to check the format of data
>as it's being imported.  (And vice versa -- when clients
>send data to servers, the servers shouldn't trust it, for
>the same reasons.)  Hence the clause above "if you control
>both the client and server" -- two different companies
>shouldn't take that approach in their client/server code.
>
>Systems are also not static.  They evolve over time.  The
>rules for what is correct/valid change over time.  If your
>clients have every reason to trust the servers (and vice
>versa) you can _still_ run into problems if it's possible
>for the protocol versions to be mismatched.  Hence the
>clause above "and can keep them in sync".
>
>- Dave
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>

----------------------------------------------------------
Murray Maloney, Esq.          Phone: (905) 509-9120
Muzmo Communication Inc.      Fax:   (905) 509-8637
671 Cowan Circle              Email: murray at muzmo.com
Pickering, Ontario 		Web:   http://www.muzmo.com
Canada, L1W 3K6    		

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)