RE: PEP Integration in RTSP

PEP is very useful in cases where I need to make sure the server will do
the right thing without first having to negotiate with the server. For
example, I may only want to COPY a resource (using one of the new WebDAV
methods) if I know the servers is a Level 2 compliant DAV server and
thus supports Versioning. Rather than having to first do a discovery on
the server and then sending the method, I can just shoot off the method
with a PEP header specifying my requirements.
  Yaron

> -----Original Message-----
> From: Ross Patterson [SMTP:Ross_Patterson@ns.reston.vmd.sterling.com]
> Sent: Friday, May 16, 1997 4:44 PM
> To: http-wg@cuckoo.hpl.hp.com; confctrl@isi.edu
> Subject: 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

------ Message Header Follows ------
Received: from zephyr.isi.edu by mars.process.com
  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
  id AA-1997May23.165912.1063.476313; Fri, 23 May 1997 16:59:16 -0400
Received: by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22076>; Fri, 23 May 1997 12:08:04 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-25)
 id <AA22064>; Fri, 23 May 1997 12:08:02 -0700
Received: from mail3.microsoft.com by venera.isi.edu (5.65c/5.61+local-28)
 id <AA27380>; Fri, 23 May 1997 12:08:01 -0700
Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30)
 id <LPFNBNV9>; Fri, 23 May 1997 12:09:56 -0700
Message-Id:
<11352BDEEB92CF119F3F00805F14F48502D2DBC3@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: 'Ross Patterson' <Ross_Patterson@ns.reston.vmd.sterling.com>,
        http-wg@cuckoo.hpl.hp.com, confctrl@isi.edu
Subject: RE: PEP Integration in RTSP
Date: Fri, 23 May 1997 12:07:57 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
Sender: owner-confctrl@ISI.EDU
Precedence: bulk

Received on Friday, 23 May 1997 14:06:21 UTC