Note, among other things, the capabilities negotiation WG starting up
now.
- dan
>-----Original Message-----
>From: Rohit Khare [mailto:rohit@bordeaux.ics.uci.edu]
>Sent: Tuesday, April 07, 1998 3:47 PM
>To: FoRK@xent.ics.uci.edu; http-ext@w3.org
>Subject: PEP over TCP, or TCPPEP
>
>
>
>Aaron Falk wrote in an IETF TCP over Satellite BOF report:
>...
>informal meeting was held with interested folks at the IETF
>to work out some details. There was general agreement that
>spoofing means different things to different people but that
>it is generally a pejorative term. To allow the group to
>focus on the technical issues rather than the emotional
>ones, I am suggesting that what we are talking about are
>proxies that enhance TCP performance. Therefore, I propose
>that we call this activity TCPPEP for, naturally, TCP
>Performance Enhancing Proxies. Eric Travis and I led the
>discussion and Eric will be posting a summary to the tcppep
>list.
>...
>
>Welcome to the crowd, folks -- here's another PEP draft that
>may actually make
>it to experimental RFC status soon:
>
>"PEP - an Extension Mechanism for HTTP"
>http://www.ietf.org/internet-drafts/draft-ietf-http-pep-05.txt
>
>And yes,one can say there is PEPTCP as much as there is TCPPEP...
>
>ObWG comment: Per the Los Angeles consensus, I agree that
>there is value in
>putting the PEP design into the RFC library as a sign of its
>maturity review,
>and potential citation in future woprk. However, iut is
>clearly not standards
>track anymore, but nor should it go all the way to
>informational; there is a
>case to be made that Eric and Henrik's code and a wide variety
>of other
>"end-user" applications at W3C justify the Experimental
>banner. The main
>result of these experiences is "negotiation is hard -- so
>don't". Rather than
>complex transfer of intent or policy, the new Mandatory-
>scheme just says what
>to do; the PEP RFC should stand as a warning that "here lie dragons".
>
>Rohit Khare
>
>PS. Thanks to Lloyd Wood for pointing out this BOF report.
>