Re: Comment on PEP draft

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.

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.

>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. There is no reason why a server can not have the same
mappings talking to different clients. Each of them have agreed on that
these are the headers they use. Therefore, they may have the same name but
may not have the same semantics. That's why small integers are fine. What
we want to avoid is that two extensions from the _same_ client step on each
other.

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

>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?

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

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

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

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Monday, 19 May 1997 13:59:36 UTC