RE: Application of Postel's Law to XML (as Re: Trust and control )

["Sheila M. Morrissey" <Sheila.Morrissey@ithaka.org>]

I think it is helpful actually to look at RFC-1122  (http://tools.ietf.org/html/rfc1122) and RFC-1123 (http://www.ietf.org/rfc/rfc1123.txt), and recall the purpose, context, actual wording, and recommendations of what Postel himself called a principle, not a law (in Pirates of the Caribbean terms, more what you'd call 'guidelines' than actual rules).

The actual recommendation is:
"Be liberal in what you accept, and
                 conservative in what you send"

More importantly, it talks a little bit more about what "accepting" means:

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
         mere human malice would never have taken so devious a course!

         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.

In other words, your application (at whatever layer of the software stack) must handle "crufty" messages gracefully -
Obviously what "gracefully" means will differ in different contexts - -but it does not *necessarily* mean you have to fully process and comprehend everything you are sent - just don't let it crash your system (again, whatever "crash" means in your application context).  

Secondly, all too often (at least from the perspective of developers who have to "accept" all sorts of content and somehow ensure that it will be usable over the very long term) not everyone pays attention to the second half of that principle:  the part about being conservative in what you send (*not* what you *do*).  This is NOT just a problem with XML - but at least the "conservative" tendency of the well-formedness principle in XML (baked into standard tools) - and still more validity constraints -- at least gives a shot at avoiding, for example,  the long-term-preservation nightmare that is PDF.

There is a place in our protocols, principles, and systems for both justice and mercy - but please, don't sell justice short.

Sheila


Sheila M. Morrissey
Senior Research Developer
ITHAKA
100 Campus Drive
Suite 100
Princeton NJ 08540
609-986-2221   
sheila.morrissey@ithaka.org
 
ITHAKA (www.ithaka.org) is a not-for-profit organization that helps the academic community use digital technologies to preserve the scholarly record and to advance research and teaching in sustainable ways.  We provide innovative services that benefit higher education, including Ithaka S+R, JSTOR, and Portico.



-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org] 
Sent: Monday, February 04, 2013 11:58 AM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Application of Postel's Law to XML (as Re: Trust and control )

Hi Folks,

Postel's Law says:

    Be conservative in what you do, 
    be liberal in what you accept from 
    others.

The intent of Postel's Law was to maximize interoperability between network service implementations, particularly in the face of ambiguous or incomplete specifications [1].

I want to fully understand what it means to apply Postel's Law to XML.

In particular, I want to compile a list of:

- Ways to be conservative in what you do.
- Ways to be liberal in what you accept from others.

Below I have made a start at such a list. Would you add to the list please?

In the following list I provide 3 things:

a. A specification that is ambiguous or incomplete, thus requiring senders and receivers to make a judgment call: how should I interpret the specification -- liberally or conservatively?

b. A way for senders to be conservative in their interpretation of the specification.

c. A way for recipients to be liberal in their interpretation of the specification.

----------
Way #1
----------
a. An ambiguous or incomplete specification:

      The data that is exchanged between
      sender and receiver must be formatted
      using markup.

b. A way for senders to be conservative:

       Send out only well-formed markup documents.

c. A way for recipients to be liberal:

      Accept and process markup documents, even if
      they are not well-formed.

----------
Way #2
----------
a. An ambiguous or incomplete specification:

      The data that is exchanged between
      sender and receiver must be well-formed
      XML.

b. A way for senders to be conservative:

       Send out only well-formed, schema-valid XML documents.

c. A way for recipients to be liberal:

      Accept and process well-formed XML documents, 
      even if they are not schema-valid.

----------
Way #3
----------
a. An ambiguous or incomplete specification:

      The value of the <country> element
      must be the name of a country.

b. A way for senders to be conservative:

       Send out only ISO-standard, 2-letter country 
       codes, e.g., US, CA, GB, DE.

c. A way for recipients to be liberal:

      Accept and process any string, e.g., US, 
      United States, U.S.A.

What other ways can specifications be ambiguous or incomplete, senders conservative, and recipients liberal?

/Roger

[1] http://queue.acm.org/detail.cfm?id=1999945

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php