Re: Comment on PEP draft

Henrik Frystyk Nielsen:
>
>At 08:33 PM 5/5/97 +0200, Koen Holtman wrote:
>
>Hi Koen,
>
>Thanks for your comments and sorry for the delay...

Hi Henrik,

Also sorry for this delay.  I finished reading the draft now, so there
are some more comments below.

[...]
>A problem with long lived mappings is that the server has to know where a
>mapping comes from, ie., what client issued the mapping. This is a problem
>as HTTP doesn't provide a good mechanism for doing this. The transport
>connection can not be used as this does not work on end-to-end extensions.
>Instead, the best way is to provide a unique extension ID when declaring
>the mapping, for example:
>
>        GET /my.resource HTTP/1.1
>        Host: some.host
> PEP: {{map http://www.w3.org/my.ext my-ext-*} {params {id abc}}
>
>and then on following requests do something like
>
>        GET /my.new.resource HTTP/1.1
>        Host: some.host
>        my-ext-id: abc
>
>This construct is very easy to put into the vary field as all the server
>needs to do is to include a header like this in the response
>
>        200 OK
>        Vary: me-ext-id
>        ...
>
>This is different from the previous model where all optional PEP extensions
>also were non-cacheable and hence I see this as being an improvement.

I do not see this as an improvement.  The contents of the
my-ext-header will be different for each user agent (because it serves
as a unique identifier), so Vary: my-ext-id has the effect of
cache-control: private.  Under the new PEP draft, there is no way to
share a cached, pep-extended response between agents.

You can only benifit from proxy caches if the same agent does exactly
the same request again while still using the same mappings, but this
case will usually have been optimised already by the local user agent
cache.

In the old (02) draft, sharing cached responses between agents was
still possible to some extent, especially (I believe) in the case that
the response ONLY has optional server-initiated extensions, so that
you do not have to send Vary: protocol.

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.

[...]
>>2) I suspect that supporting header mapping will not be simple.
[...]
>I am interested in hearing why you think why it is not simple!

Now that I have read the whole draft, I agree that it is simple.
However, I also think that this it does not lead to caching which is
efficient enough.

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.

All in all, I must admit that I liked the previous draft better. The
old draft had some problems with cache efficiency too, but I think
that the approach to solving these problems in the new draft actually
makes things worse.  I have not thought this through, but mappings
initiated by the *server* may get us better sharing opportunities.

Some other comments:

1.

   4.2. Operational Overview

          * An extension is assigned a URI; in addition to a human-
            readable specification of an extension, a machine-readable
            implementation or description of the extension is published
                                                           ^^^^^^^^^^^^
            at that address.

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?

2.

   6.1. Header Field Mappings

      Clients SHOULD NOT overload well-known or widely deployed header
      fields with new semantics unless the new semantics are a superset
      of the existing semantics so that the header fields still can be
      interpreted according to the old semantics.

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-'.

3.

   11.2. Interaction with Existing HTTP/1.1 Headers

               As both the content encoding mechanism and the
      PEP mechanism is ordered, using both MAY lead to ambiguous
      situations. Simultaneous use of both mechanism is therefore
      strongly discouraged.

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.

4. 

    11.3. Identifying the Source of a Mapping

          * an HTTP cookie provided with every request identifying the
            originating client, see [RFC2069];

The cookie spec is 2109, not 2069.

          * HTTP authentication credentials provided with every request
            identifying the originating client, see [RFC2068]

HTTP authentication credentials identify users, not clients.  A user
may have multiple clients running, so authentication credentials are
not usable as source identifiers.  

      If none of the above applies then the server MAY look for a From
      header field in the request. This MUST NOT be considered a
      reliable mechanism and explicit care SHOULD be taken by the server
      not to rely on 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.


>Henrik

Koen.

Received on Monday, 19 May 1997 08:01:13 UTC