Subject: PEP Integration in RTSP

From: Rob Lanphier <[email-masked]>
Date: Fri, 16 May 1997 13:40:25 -0700

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?

I'm crossposting this to the confctrl mailing list for the MMUSIC group
[3], and the HTTP-WG group alias [4] in order to get some input from both
groups.  Since RTSP has a very HTTP-like look and feel (though very
different in state and data delivery issues), it makes sense to share
mechanisms which should be common between the two.

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.  

The reason why we made this decision is that it allows cleaner PEP
integration into RTSP.  This allows RTSP entities to forgo prepending
"PEP-" to all methods that require PEP.  The new language within RTSP would
essentially say that servers MUST parse the "PEP:" and "C-PEP:" fields and
MUST return "420 Bad Extension" when there is a PEP extension of strength
"must".

Prior to talking things over with the PEP authors, I had sent a note to the
confctrl alias about PEP integration, which I've included below for the
http-wg alias members' benefit.  There hasn't been a lot of comments about
this, and I suspect it's because people haven't had the opportunity to look
over the PEP specification.  Now that there is a more concrete proposal on
the table and that the direction from us as RTSP authors is clearer, I'd
like to solicit people's comment on this now.

Thanks
Rob Lanphier
Progressive Networks

Resources:
[1] Real Time Streaming Protocol (http://www.real.com/prognet/rt)
[2] Protocol Extension Protocol
(http://www.w3.org/pub/WWW/Protocols/PEP/Overview.html)
[3] IETF's MMUSIC working group
(http://www.ietf.org/html.charters/mmusic-charter.html)
[4] IETF's HTTP working group
(http://www.ietf.org/html.charters/http-charter.html)

-------------------
Date: Thu, 17 Apr 1997 13:40:16 -0700
To: [email-masked]
From: Rob Lanphier <[email-masked]>
Subject: RTSP: 2. Use of PEP for Require and Transport-Require

The Require field (see section 11.17 of the current
draft) provides a simple mechanism for capability
query.

A standard for providing this functionality (and
more) is PEP, an option negotiation method from the
HTTP working group.

The authors are mostly in agreement that PEP is/will
be a really good thing, and the only question is
whether it can immediately placed into the RTSP
specification, or whether there should be an
intermediate mechanism pending the completion of PEP.

The general feeling in Memphis was that people needed
more time to look at PEP, and make sure that some
such mechanism is needed. There would be more
deliberation on the mailing list on this topic before
any sort of decision one way or another is made.

Some folks thought of this as something that can be
added later, to which Henrik Frystyk Nielsen from the
W3C noted that there is a need for some option
negotiation core to the protocol, which was a lesson
learned from the original HTTP specification.

---

From: Mark Handley <[email-masked]>
Date: Mon, 19 May 1997 12:13:47 -0400

>the only question remains:  how will this be integrated?

HTTP has evolved to be all things to all people (kind of a universal
transport/transaction protocol), and to need to carry an almost
infinite variety of header fields, which is why a protocol like PEP is
now required.

Do we really believe that RTSP needs to evolve in the same way?

Mark

---

From: [email-masked] (Koen Holtman)
Date: Mon, 19 May 1997 18:27:11 +0200 (MET DST)

>the only question remains:  how will this be integrated?

A word of warning here: PEP is not a finished product, and I have no
idea how long it will take us (the HTTP-wg) to converge on PEP.

>Progressive Networks

Koen.