Re: PEP Integration in RTSP

http-wg@cuckoo.hpl.hp.com writes:

>The authors of RTSP [1] and authors of PEP [2] have been discussing how to
>integrate PEP into RTSP as the standard extension mechanism for RTSP.  The
>authors of RTSP have very strong consensus now that we will use PEP, and
>the only question remains:  how will this be integrated?


Some of us, myself included, don't believe PEP is such a great idea.
Its bias towards nonstandard extensions with downloadable
implementations just doesn't jive with the '90s "safe computing" world.
I'll have a very hard time convincing any of my customers to download
anything into the webservers my company sold them, no matter who's
responsible for the code.  My personal expectation (not necessarily
Sterling Software's, as we haven't discussed PEP much) is that PEP in
the traditionally high-security, high-reliability mainframe world is
dead on arrival.  I've held off commenting to date as I expect this is
both a minority viewpoint and an environment where no matter what
changes are made (short of using URNs to identify already-embedded
"extensions"), any form of PEP will be simply unacceptable.

>In the discussions between authors of RTSP and PEP, we came to the
>conclusion that PEP complience in RTSP should be mandatory, which would
>make the relationship between PEP and RTSP different than the relationship
>between PEP and HTTP.

If you're going to use PEP, making it a MUST from the start is a very
good idea.  Some of the weirdness in PEP today derives from HTTP 1.x's
"don't ask, don't tell" attitude towards unrecognized header fields.
That was a wise choice at the time, and remains so, but it makes PEP a
little odd as a result.

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Friday, 16 May 1997 16:59:56 UTC