Re: New PEP draft available as ID!

> I realize that PEP is a lot more powerful than a simple "check the
> switch" solution but in all the real world scenarios I am looking at,
> such as deploying DAV, I don't seem to need anything more than the
> attribute. Has someone else had a different experience?

While I agree with the particular points I don't agree with the conclusion.

I believe that the problems with PEP could be solved by abandoning the
idea of sending meta-protocol information along with the connection
data.

Instead of doing this I would like to see a single tag to define the
semantics of any x-tended headers and how proxies should deal with them.
The tag would be of the form :-

PEP-Extension: <version> <url>

Where version is the version of the PEP specification format and uri is
the location (yes it is a location in this case) where the specification
can be downloaded from.

I understand that there are occasions in which this will not work such 
as intranets not connected to the Internet and intergalactic spacecraft.
I think that attempting to address these corner cases by sending a
couple of hundred bytes of verbiage along with every message is a bit 
broken and unlikely to fly in any case.

PEP only specifies the grammar of the protocol, not the semantics. It
can only solve the problem of proxies and other intermediaries that need
to know something about the tags being passed.

I think the problem of extending the protocols has mainly been that until 
recently there have not been clients that are extendable. NCSA Mosaic
has been a long time withering on the vine. I think that the new generation
of clients may solve many of the percieved problems.


	Phill

Received on Wednesday, 30 April 1997 15:47:46 UTC