Re: draft-ietf-http-pep-02

Rohit,

Some comments:

1. I agree with you that the token/tspecials/... syntax definitions
should stay in the draft.  Readers should not have to trace references
for such things, and won't anyway.

2. I agree with most of the other readability comments people have
made, and would like to mention in addition that I found it very
painful to read the 3.[1234].[1234] sections.  I hope you can come up
with a more generalized description of this stuff.

3. You talk a lot about `must begin using the specified extension'.
What exactly does `begin using' mean?  Does the use end?  The JEPI
draft talks about `the protocol module associated with the specified
protocol will be invoked when ...'.  

It seems to me that you are setting up PEP to act as a generalized
system by which a chain of HTTP agents can activate modules connected
to them and mediate between these modules.  This seems to imply that
there can be state, both in the HTTP agent chain and in the connected
modules.  I think it is very important to clearly define which state
is present where.  Maybe the ideal scheme never has state in the HTTP
agents, or only has state in the agents as an optimization device.

You may want to consider a semantic model which does away with the
concept of `beginning to use'/`activating' altogether, this might
simplify state issues.

You may want to consider discussing the nature of protocol modules
very early in the draft, you have some stuff in there now but I'm
missing a discussion of state in modules and of how modules might do
autonomous actions like sending the first PEP header in a negotiation
sequence.  (See for example operation 3 in JEPI.  The NetScape ONE
white paper I read recently makes a lot of fuss about triggering
modules through HTML elements.  There seems to be some `outside the
scope of... boundary here that needs to be clearly defined.)

I think that to determine if PEP is powerful enough, we will first
need to answer the question of what things we want modules to be
capable of doing.

4. You write:
>   Another aspect of the PEP model is that protocol extensions can have
>   negotiable parameters.  Unlike previous proposals which model
>   extensions as binary have/don't have features, PEP expects protocol
>   extensions will be able to handle different versions of a particular
>   protocol, invocation of ``compatible protocols'', and the selection of
>   compatible modes from several that might be advertised.

Who negotiates these negotiable parameters and who selects compatible
modes?  The HTTP agents? The protocol extensions themselves?  Both?

5. The question of interaction with proxy caches is an interesting
one.  It seems that in general only the author of a server-side PEP
module will be able to determine the cachability of the response if
the module is applied.  This seems to put cachability considerations
beyond the scope of PEP itself.  On the other hand, maybe generalized
proxy mechanisms, like mechanisms to automatically downgrade responses
before/after caching, are needed if module authors are to achieve good
cachability.

6. You write:
>     * ``This agent has and is using (or does not have and isn't using)
>       the http://w3.org/DES protocol extension with mode parameter CFB
>       and header DES-Info:''

This example raises an interesting question: What happens if I define
a `Digital Epibration Service' protocol http://wuxta.com/DES with a
header DES-Info:?  It seems that PEP cannot prevent a header name
collision if both extensions are used at the same time.  So it seems
that PEP cannot support the safe use of unregistered HTTP headers by
pluggable extensions: the whole {headers *<token>} stuff could just as
well be removed.

7. You write:
>   Connection-scope extensions can remain backward-compatible by listing
>   every associated header and the name of the extension in the
>   Connection: header.

I don't understand what you want to say here.

8. You write:
>          If a
>          reference ends in "*", it should be understood as a wild-card
>          character (particular implementations may choose to only
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
>          recognize restricted applications of "*", e.g. `only in the
>          last component of http: URLs').

I can't see how you can unambiguously negotiate if you don't know what
wildcarding the implementation at the other side supports.

9. The * is a legal character in URLs, but you also use it as a
wildcard character in the {for ...} stuff.  Doesn't this raise various
sticky ambiguity problems?

10. It seems that there are also potential spoofing problems for
multi-user origin servers: author X could do a denial of service
attack on the content of author Y by suggesting that Y's resources
require or support some PEP extension that they do not require or
support.

11. I'm not happy with your use of the 220 code to indicate `uses
protocol extensions'.  I believe the use of extensions is already
indicated by the presence of a Protocol header; cachability could be
restricted if necessary with the usual mechanisms.  Requiring 220 in
some cases seems to prevent use of PEP if I want to generate a not
modified/partial content/see other response.

12. Could you comment on the state of mechanisms like JEPI which use
PEP?  Is there already an installed PEP base we need to stay
compatible with (please say no)?  Are there publicly available test
implementations?

13. Like Ted Hardie, I'd like to see a specification draft, preferably
a specification as complete as possible.  The devil is in the details,
and I can't see all the details yet, in particular those concerning
state, after reading the discussion draft.  The previous
(specification oriented) PEP draft left lots of details uncovered.
One often needs to consider the details to know how much power one can
get before the complexity due to feature interaction starts exploding
all over the place.

Koen.

Received on Sunday, 25 August 1996 15:45:44 UTC