RFC 3930 on extensibility and versioning

Hello QA IG,

As a contribution to our recurrent discussions around extensibility and
versioning, I've spotted that RFC 3930 (on the Documents vs Protocol
point of view) has a section devoted to extensibility and versioning:
"""
2.3.3.  Extensibility of Processing

   DOCUM: The document oriented don't usually think of extensibility as
      a major problem.  They assume that their design, perhaps with some
      simple version scheme, will meet all requirements.  Or, coming
      from an SGML/DTD world of closed systems, they may assume that
      knowledge of new versions or extensions can be easily and
      synchronously distributed to all participating sites.

   PROTO: Those who are protocol oriented assume that protocols will
      always need to be extended and that it will not be possible to
      update all implementations as such extensions are deployed and/or
      retired.  This is a difficult problem but those from the protocol
      point of view try to provide the tools needed.  For example, they
      specify carefully defined versioning and extension/feature
      labelling, including the ability to negotiate versions and
      features where possible and at least a specification of how
      parties running different levels should interact, providing
      length/delimiting information for all data so that it can be
      skipped if not understood, and providing destination labelling so
      that a process can tell that it should ignore data except for
      passing it through to a later player.

"""
ftp://ftp.rfc-editor.org/in-notes/rfc3930.txt

Nothing brand new with regard to what is currently described in the Web
Architecture document and in SpecGL, but I found the presentation of the
different approaches (Doc vs Protocol) interesting in this context.

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org

Received on Thursday, 6 January 2005 12:44:51 UTC