[Fwd: Re: PEP draft for review]

I thought I could shorten the name of the maling list...
I was wrong. It bounced.

attached mail follows:

Koen Holtman wrote:

> You seem to have moved away from the idea of PEP being a mechanism for
> activating extensions, towards the idea of PEP being a way for
> extensions to piggyback data on top of a HTTP connection.

Hmmm... it has always been both in my mind. But each of us
can have his own idea about what the mechanism is for, as long
as we agree on the protocol itself.

>  I like that
> a lot because the activation stuff in the previous draft had me very
> worried.

I'm glad this spec makes you less worried ;-)


> >                extension-decl   = "{" extension-id *ext-info "}"
>                                         ^^^^^^^^^^^^
> You have not defined extension-id.

Silly me... I hope it was obvious from the prose that it's a URI.


> >                bag              = "{" bagname 1*LWS *bagitem "}"
>                                                 ^^^^^
> 
> The 1*LWS should be deleted.

...

> Note that an URI may have a } in it.  I don't know how much of a
> problem this is for parser writers.  You may want to consider quoting
> the URI.

Hmm... good point. I'm pretty sure the previous PEP draft required
a space the URI. I think that's what the 1*LWS above is for (is
there a better way to express it in the HTTP BNF?)

I'll add a clarifying note in the prose.

And I'll make it clear that a URI shoud be parsed as "anything up
to the next space."

> >         GET /a-document HTTP/1.1
> >         Protocol: {http://some.org/an-extension}
> >
> 
> OOPS!  You forgot to put in a Host header.  This happens in later
> examples too.

Good catch. Fixed.

> 
> >             Protocol-Info    = "Protocol-Info" ":" 1#policy-decl
> [...]
> >             scope            = "{" "scope" ( "conn" | "origin" ) "}"
> 
> You have Protocol and C-Protocol headers.  Why don't you have
> Protocol-Info and C-Protocol-Info headers?

Protocol C-Protocol are request/response headers: they give information
about the transaction, and a distinct header field name is necessary
for proper integration with the HTTP 1.1 Connection: header field
mechanism.

Protocol-Info, on the other hand, is an entity header: it applies
to resources, either those explicitly named using the "for" syntax,
or contextually implied from the rest of the transaction (which is
explicit in a request, but implicit in a response). Its relavence
goes beyond the transaction, and hence issues of freshness,
authenticity,
etc. are much like Last-Modified. For this purpose, a distinct
header field name is not needed, so I went with putting the
scope info in the payload of the header field.

Does that make sense? Is there something I could add to the draft
to clarify?


> >                   This mechanism is redundant, but
> >   provided for the case where the use of header fields is essential.
> 
> Can you include an example of such a case where header fields are
> essential?  If you don't need  it to be compatible with some
> existing practice, I suggest deleting this redundant mechanism
> completely.

A few of us considered that. I'd like to hear from a few more folks
about this. One existing practice along these lines is PICS. But
I suspect it's not the only one -- I suspect other folks will want
to use PEP to identify extensions they've developed that use headers.

I'd like to hear some more opinions/experience about this before
I strike it from the draft.

> >   Mult-Transaction Negotiation
> >
> >      An earlier draft of PEP included a mechanism for multi-transaction
> >      negotiation. Implementation experience showed the need to identify
> >      clients across transactions, which the mechanism did not provide.
> >
> >      It is possible, within the design specified here, to do multi-
> >      transaction negotiation within an extension (for example, by
> >      putting information to disambiguate conversation threads in the
> >      params).
> 
> I suggest that you define a standard convention for such
> disambiguation with params.

The future work section is sort of a laundry list of things that I
expect we'll implement in jigsaw/libwww, but we don't have enough
direct experience to suggest it to the community.

I'll write down the first thing that somebody can demonstrate with some
code. I expect to do this with Jigsaw/libwww, but if somebody beats
us to it, I wouldn't mind at all!

Thanks for the careful review!

The resulting diffs are attached. I don't think this is enough stuff
to issue a new internet draft, but if anybody wants one, just say the
word.

I just added a link to my intermediate draft with these changes[1]
to the PEP page[2].

Dan

[1] http://www.w3.org/pub/WWW/Protocols/PEP/pep-spec.html
$Id: pep-spec.html,v 1.10 1997/02/11 16:48:09 connolly Exp $ 

[2] http://www.w3.org/pub/WWW/Protocols/PEP/