Re: PEP draft for review

Dan,

I just read the new PEP draft.  I think congratulations are due on the
progress made: the new draft has made me optimistic about PEP being
completed soon.  While a lot of details still need to be filled in,
you seem to have solved the problem of clearly delineating the
functions of the PEP framework.

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.  I like that
a lot because the activation stuff in the previous draft had me very
worried.

Some comments: (quotes are from the draft)

>   3.1. The Protocol Header Field
>
[...]
>                Protocol         = "Protocol" ":" 1#extension-decl
>                extension-decl   = "{" extension-id *ext-info "}"
                                        ^^^^^^^^^^^^      
You have not defined extension-id.

>                ext-info         = params | headers | enc
>                params           = "{" "params" *bagitem "}"
>                headers          = "{" "headers" 1*token "}"
>                enc              = "{" "enc" 1*token "}"
>
>                bag              = "{" bagname 1*LWS *bagitem "}"
                                                ^^^^^

The 1*LWS should be deleted. I assume at least that you do not want
the bag {a{b c}} to be illegal.  LWS is implied by the HTTP grammar
(though the implied LWS definition in 1.1 probably needs to be
upgraded, as some 1.1 headers use LWS instead of tspecials as
delimiters between tokens).

>                bagname          = token | URI

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.

>                bagitem          = bag | token | quoted-string
>
>      For example:
>
>         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.


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

>5. Extension Header Fields
>
[...]
>                   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.

>Future Work
[...]
>   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.  I like disambiguation with params much
better than disambiguating with cookies: the user may have disabled
cookies because of privacy considerations.


By the way, about the interaction with transparent content negotiation: I
defined the TCN response rules in such a way that you can safely put PEP
extensions on TCN variant resources.  (If anybody is wondering why section
10.2 in the TCN draft needed to be so long and detailed: this is why.)

Koen.

Received on Monday, 10 February 1997 12:48:21 UTC