Re: PEP Integration in RTSP

Henning Schulzrinne <schulzrinne@cs.columbia.edu> writes:

>                                     I seem to remember from the PEP
>draft that the URLs serve to (a) identify (b) describe the extensions. I
>don't see how downloadable extensions would work, given the diversity of
>servers, platforms, languages, etc.

I agree, although Java and the "servlet" movement might change all that.
But frankly, I'm more concerned about the "nonstandard" part of my
"nonstandard downloadable" comment.  I see PEP as primarily advancing
the Balkanization of HTTP that began when the major browsers started to
deploy unilateral and (at the time) unpublished extensions to both HTTP
and HTML.  Experimentation is good for interoperability, but variant
"standards" are not.

>                                    As far as I can tell, the draft
>doesn't mention downloadable extensions.

>From the 28 April 1997 (level 03) PEP draft, section 4.2, "Operational
Overview", as posted to http-wg:

  "The PEP mechanism is designed to accommodate dynamic extension of
   clients, servers, and proxies by software components as follows:

       * Clients and servers are implemented with software component
         interfaces that allow dynamic installation of extension
         facilities.
       * An extension is assigned a URI; in addition to a human-
         readable specification of an extension, a machine-readable
         implementation or description of the extension is published
         at that address.
       * If a message that refers to an extension is received by a
         party that has no awareness of the extension, the receiver
         can dereference the extension's identifier and dynamically
         load support for the extended facility."

And again in section 12, "Security Considerations":

   "* Dynamic installation of extension facilities as described in
      the introduction involves software written by one party (the
      provider of the implementation) to be executed under the
      authority of another (the party operating the host software).
      This opens the host party to a variety of "Trojan horse"
      attacks by the provider, or a malicious third party that forges
      implementations under a provider's name. See, for example,
      section 7.4.2 of RFC1521 for a discussion of these risks[.]"

The level 02 draft contained a section entitled "Bootstrapping and
Dynamic Loading" that is not present in level 03, although it is cited
by name twice.  It read:

   "The extension definition MAY be made available in different
   representations.  For example, a software component that
   implements the specification MAY reside at the same address as a
   human-readable specification (distinguished by content
   negotiation).

   The human-readable representation serves to document the extension
   and encourage deployment, while the software component to allows
   clients and servers to be dynamically extended."

Nothing here requires that a server go obtain the extension and run it,
but market pressure will inevitably lead there, especially the first
time either Netscape or Microsoft publish a downloadable extension.
Just look at the Netscape plug-in market - it's what HTTP will wind up
looking like after that.

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Saturday, 17 May 1997 08:01:22 UTC