Re: Comment on PEP draft

Henrik Frystyk Nielsen:
>
>At 04:58 PM 5/19/97 +0200, Koen Holtman wrote:
>
>>Still, both drafts allow significantly less sharing of extended
>>responses than can be had by writing an RFC which defines a unique
>>request header for the extension.  This is bad.
>
>Let me take a step back and explain what PEP is intended to do. PEP
>provides HTTP with a mechanism for dynamically extending methods,
headers
>and status codes. Doing that, it supersedes any x- scheme currently
used
>and in addition allows for (but does not require) automated download
of
>extensions when we get a trust management infrastructure.

I agree so far...

>But, as (I think) Yaron said at some point, the price you win by going
>through 2 years of scrutinizing IETF specification work is a token.
This is
>still valid and PEP will not change this.

My point is that the above statement is _wrong_ for the current PEP
draft.

The current PEP draft does not allow sharing of cache entries for
extended responses.  2 years of scrutinizing IETF specification work
_will_ allow allow sharing of cache entries for extended responses,
and this is a significant win for some extensions.  Picking a random
request header name and hoping that nobody else uses it gives you the
same win over PEP.

This is bad.

Here is a case which illustrates this problem in PEP: Consider two
user agents A1 and A2, which both can decode the gzip encoding, and
which are connected, via a shared cache C, to a server S, which can
send either unencoded or gzipped responses.

  A1 ----\
          C-----S
  A2 ----/

If you negotiate on encodings with the HTTP accept-encoding field, the
server can send Vary: accept-encoding in its response when A1 does a
request, and A2, which sends the same accept-encoding header as A2,
will get the cache entry when doing a later request.  Result: sharing.

If you negotiate on encodings with PEP, A1 sends its mapped ext-of-A
request header, and the server sends a response with vary: ext-of-A.
A2 will map the same extension to a different ext-of-B request header,
so it will not get A's vary: ext-of-A cache entries.  Result: no
sharing.

>>Also, if a server allows an extended response with the header X to be
>>cached for 10 days, it will have to refuse a re-mapping of X to
>>something else for 10 days to avoid any clashes.  The server-side
>>overhead for keeping track of all this may be large.
>
>No, it doesn't.
[...]

OK, I see now: the server hands out the unique small integers, and it
prevents any clashes by making them all different.  So it will never
have to refuse a header mapping because of potential clashes.

This integer trick is not immediately obvious to me; you should
document such things in the draft.  As I said in Memphis, PEP needs to
tell in detail what methods to use to prevent problems with 1.0 and
1.1 caches.  1.0 caches are too broken, and 1.1 caching is too
complex, to leave the task of figuring this out to the individual
implementers.

>>How is this publiblishing done?  By putting a link in the
>>human-readable specification for the user to click, or with some
>>medadata mechanism?  If so, which metadata mechanism?  Also, what
does
>>`a machine-readable description of the extension' look like and what
>>is the machine supposed to do with it?
>
>It is not for PEP to decide how a party wants to publish an extension
nor
>how it wants to present it to the user. Using a PEP extension can have
>legal or other social implications which is outside the scope of PEP.
PEP
>is a wire protocol, not a data format and there is no reason why it
should
>define a machine-readable description.

Putting things out of scope can go too far: if you leave big holes
which implementers are supposed to fill, implementers will fill them
in a non-interoperable way, which means you end up with something
non-interoperable, and your 2 years of scrutinizing IETF specification
work will have been for naught.

I think PEP needs to define at least _one_ standard
least-common-denominator way of publishing an extension: there needs
to be a way of dereferencing the extension URI which is guaranteed to
get you a human-readable description (or and error that none is
available).  If you do not define this, you will leave a big hole.

>>This is entirely to weak: PEP needs to partition off a particular
part
>>of the header namespace (for example all headers which start with
>>`p-') for use in PEP mapping, and guarantee that PEP clients leave
the
>>rest of the header namespace alone, except when extending a known
>>header.  Else we will see situations like `this internet draft cannot
>>define the id-blah header because the PEP implementation in
>>SillyUnknownBrowserX V2.3 maps to all headers which start with id-'.
>
>Header mappings are _dynamic_ - not static, so I can't see how this
can be
>a problem?

Suppose HTTP/1.2 defines a new optional id-blah request header to be
added to HTTP requests by (non-PEP-aware) HTTP/1.2 proxies.  If a
PEP-aware 1.1 user agent communicates with a PEP-aware 1.1 origin
server through such a proxy, and the user agent maps the 1.2 id-blah
header to the pizza extension, you get multiple pizzas if the proxy
decides to add id-blah to the request.

>>PEP cannot strongly discourage plain 1.1 caches to do somehting, and
>>HTTP/1.1 allows plain HTTP/1.1 caches to add content encodings on the
>>fly.  So there WILL be amgiguous situations.  This needs to be fixed.
>
>The no-transform cache directive avoids this situation. I will add the
>words explaining this.

OK, no-transform will solve it.

>>The cookie spec is 2109, not 2069.
>
>Oups - sorry.
>
>>HTTP authentication credentials identify users, not clients.  A user
>>may have multiple clients running, so authentication credentials are
>>not usable as source identifiers.  
>
>These clients will then not be able to share the extensions. There is
>nothing wrong in this.

No, non-unique source identifiers uses as if they were unique will
lead to mapping clashes which won't be noticed by the origin server.
There is something wrong with this.

>>I think that looking at authentication and From fields should be
>>explicitely forbidden.  Given that PEP is supposed to support payment
>>protocols, the language above is entirely too weak.
>
>There may be situations where this is fine and there is no reason to
forbid
>it if this is the case.

_If_ you define a way for a payment extension to find out that
it is connected to a PEP protocol stack stupid enough to use From
headers, so that it can barf appropriately, _then_ you can get away
with not forbidding this case and still have a useful protocol.  But
only then.

>Thanks,
>
>Henrik

Koen.

Received on Wednesday, 28 May 1997 11:59:48 UTC