Subject: RE: PEP Integration in RTSP

From: Eric Fleischman <[email-masked]>
Date: Mon, 19 May 1997 08:39:37 -0700

The WG's mailing list has been silent for quite a while. During this
time the RTSP authors have apparently been actively debating PEP. This
makes it difficult for those who were not a party to these discussions
to completely understand what the authors are exactly thinking.

Therefore, I'd like to request that the authors please post to the WG
the specific wording changes they would like to see made to the latest
(i.e., 02) version of the RTSP document to express their consensus
position. I fear that without such a clear statement we may
inadvertently make inaccurate assumptions concerning their consensus.

> -----Original Message-----
> From:	Rob Lanphier [SMTP:[email-masked]]
> Sent:	Friday, May 16, 1997 1:40 PM
> To:	[email-masked]; [email-masked]
> Subject:	PEP Integration in RTSP
> 
> 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: Henrik Frystyk Nielsen <[email-masked]>
Date: Mon, 19 May 1997 14:33:37 -0400

>to completely understand what the authors are exactly thinking.

Sorry for the delay - the reason was that I have been working on a new
version of the PEP draft which would separate out the specific interactions
with HTTP. This is so that it would be easier for you guys to look at the
PEP draft and use the generic parts of PEP in RTSP. I am about to wrap it
up and publish it as an ID by the end of the week. In the mean time, let me
give you my view of the situation:

PEP is designed to support dynamic extensibility of HTTP methods, headers,
and status codes. Before describing in detail how PEP does this, it is
constructive to have a look at how methods, headers, and status codes
behave in both HTTP and RTSP:

Methods

The method token in a request indicates the method to be performed on the
resource identified by the Request-URI. Methods need a priori agreement of
semantics and can not be extended dynamically. If an server does not know a
method, it must report an error message, see RFC2068 section 5.1.1. A
limitation of the method space is that a request can only contain a single
method. Hence, it is not possible to support multiple, simultaneous
extensions unless having a multiplicity of methods.

Status Codes

The status code element is a 3-digit integer result code of the attempt to
understand and satisfy the request. Status codes are like method tokens in
that there can only be a single status code in a response. However, status
codes are somewhat easier to extend, as unknown status codes must be
treated as the x00 code of that class, see RFC2068 section 6.1.1. For
example, a new status code, 223 (My New Code) would default to 200 (OK).

Headers

Header fields can be used to pass information about any of the parties
involved in the transaction, the transaction itself, or the resource
identified by the Request-URI. The advantage of headers is that the header
space is relatively open compared to that of methods and status codes. New
headers can be introduced and must be ignored if the recipient does not
recognize the header without affecting the outcome of the transaction, see
RFC2068 section 7.1

As a result of this, PEP is designed to use the header space for describing
extensions and not directly use methods or status codes. Instead, PEP
introduces a placeholder in the method space and status code space
respectively guaranteeing that all interactions with existing applications
perform according to the PEP specification.

Instead of the method name placeholder, however, which is required in HTTP,
RTSP can do better as it can say that PEP headers MUST not be ignored. The
advantage of this is that RTSP from day one has a dynamic extension model
which covers methods, headers, and status codes.

HTTP has lacked this for a long time and the result is that people invent
their own methods and don't tell each other about them. It is hard to say
exactly what the evolution of RTSP will be and in any case, I am sure that
you know much better than I, but from a general point of view it is hard to
see why RTSP will not develop as any normal protocol. Note, that this is
not only valid for HTTP but also SMTP, NNTP, FTP, etc.

The next question is then - how much is needed to make room for PEP in
RTSP? This has been the main topic in the discussions that you refer to.
The minimum answer is that the only thing needed is that an RTSP server
MUST recognize and parse the PEP headers and respond with an error if it
sees an extension of strength "must".

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <[email-masked]>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 19 May 1997 13:00:46 -0700

At 12:13 PM 5/19/97 -0400, Mark Handley wrote:
>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?

Here's what is driving this.  The current RealAudio and RealVideo products
have an extension mechanism in it.  This has been an absolutely vital part
of keeping the protocol sane and yet still allowing the rapid deployment of
new features.  The current RealAudio mechanism is relatively simple, and
really not unlike the "Require:" field in the current RTSP draft.

Henning was rightfully concerned that we were needlessly diverging from the
direction of HTTP by having our own extension mechanism, and proposed that
we use PEP.  PEP is more powerful than "Require:" and "Transport-require:",
and thus is more complicated.

So, based on your statement above, there are two questions here:
*  Do we need an extension mechanism?  I'm very adament that this must be a
feature of the protocol, given Progressive Networks' past experience with
this.
*  Should we use PEP?  I really think it's the right thing to do, given
that we are proposing an extension mechanism, and since the PEP authors
have clearly put a lot of thought into this problem.  However, there are
risks associated with this:  mainly, that PEP is an Internet draft, and
therefore must reach "proposed standard" before it can be a requirement of
RTSP (i.e. before RTSP can reach "proposed standard").

As HTTP has shown, not having an extension mechanism does not mean that
vendors won't add features to the protocol.  Rather, what it means is that
they will do it in ways that may break existing implementations.  I think
the best thing about PEP is that it allows unextended clients a way of
gracefully  handling extensions, and that is a very desirable feature.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 22 May 1997 10:04:27 -0700

At 03:53 PM 5/19/97 -0700, you wrote:
>
>> So, based on your statement above, there are two questions here:  * Do
>> we need an extension mechanism?  I'm very adament that this must be a
>> feature of the protocol, given Progressive Networks' past experience
>> with this. 
>
>It might help clarify things if we had a few concrete examples of what
>kinds of things this extensibility would be useful for (and perhaps some
>examples of where it wouldn't be useful.)

I'll be working on better examples than what I'm presenting below.  The
idea is that we want to make sure that we have a way of recovering from
oversights in the protocol design.  Obviously, for me to point out things
now that we will consider to be oversights is rather difficult, since of
course there are no oversights in our design :)

Rather than me trying to contrive a new feature which may start an argument
about the feature itself, I'm going to take a non-controversial feature
that already exists in protocol, and consider the hypothetical situation
that we overlooked this in our original design.

Let's take the "Range:" field on the PLAY method.  If we had accidently
left this field out, retrofitting it on a protocol that doesn't have
something like PEP would be rather difficult, since fields are ignored if
they aren't recognized.  This would mean that a client requesting to play
the last 30 seconds of a clip may potentially get the beginning of the
clip, which it would then have to shut down and figure out how to deal with
that contingency.

In a stateful protocol like RTSP, an added function of PEP is to freeze the
state machine when there is a problem rather than having the server plow
ahead in the state machine when the client isn't necessarily ready for it
to do that.  This would force the client to figure out how to back out the
unintentional state change on the server.

Some of the scenarios at the W3C site apply here as well:
http://www.w3.org/pub/WWW/Protocols/PEP/PEPScenarios.html

In particular, look at Scenario 2, 4, 5, and 6.

Another possibly applicable feature is the HTTP Sticky Headers feature:
http://www.w3.org/pub/WWW/Protocols/HTTP/Sticky/

Whether or not this is desirable is certainly debatable, but the idea of
having a standard way for a client to let the server know how the
appropriate way to deny a feature is a very nice thing.

I hope this helps.

Robla

---

---

From: Yaron Goland <[email-masked]>
Date: Fri, 23 May 1997 12:07:57 -0700

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

> From:	Ross Patterson [SMTP:[email-masked]]
> Sent:	Friday, May 16, 1997 4:44 PM
> To:	[email-masked]; [email-masked]
> Subject:	Re: PEP Integration in RTSP
> 
> [email-masked] writes:
> 
> 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.
> 
> 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

---

From: [email-masked] (Yaron Goland)
Date: Fri, 23 May 1997 17:03:23 -0400

------ Message Header Follows ------
<[email-masked]>
From: Yaron Goland <[email-masked]>
To: 'Ross Patterson' <[email-masked]>,
        [email-masked], [email-masked]
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: [email-masked]
Precedence: bulk

---

From: [email-masked] (Yaron Goland)
Date: Fri, 23 May 1997 18:47:35 -0400

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked],
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

---

From: [email-masked] (Yaron Goland)
Date: Fri, 23 May 1997 20:05:05 -0400

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked],
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked] (goncalves),
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

---

From: [email-masked] (Yaron Goland)
Date: Fri, 23 May 1997 21:23:22 -0400

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked],
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked] (goncalves),
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked] (goncalves),
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:05:05 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

---

From: [email-masked] (Yaron Goland)
Date: Fri, 23 May 1997 23:32:44 -0400

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked],
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 17:03:23 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked] (goncalves),
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 18:47:35 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked] (goncalves),
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 20:05:05 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]

------ Message Header Follows ------
From: [email-masked] (Yaron Goland)
To: [email-masked] (goncalves),
        [email-masked] ('Ross Patterson'),
        [email-masked] (http-wg), [email-masked] (confctrl)
Organization: Process Software Corporation
Date: Fri, 23 May 1997 21:23:22 -0400
Subject: RE: PEP Integration in RTSP
Sender: [email-masked]