Re: draft-ietf-http-pep-02

In general, this is a well-written draft and I very much appreciate
the early emphasis on how PEP differs from the normal extension process
of adding header fields.  However, it does not consider the other extension
mechanisms of methods, media-types, content-codings, transfer-codings,
and status codes.   In particular, I think you should justify the use
of ordered header fields instead of encapsulated media types and how
that affects the interpretation of an HTTP message [if it does].

Spec-wise, please do not include the colon when referring to a
header field, e.g.,

>    Using PEP in this way also solves the next logical problem: how can a
>    client request a server to initiate vending PICS labels? The same
>    structure for a Protocol: can be reused in a Protocol-Request: asking
>    the counterparty to start using the specified extension.

should be either "for a Protocol header field", "for a Protocol field",
or simply "for Protocol" (assuming you are defining Protocol in the BNF).
The reason is that the ":" is not part of the field-name (it is the
separator) and people have a habit of misinterpreting the syntax when
it is glommed together.

Also, I think it would improve readability if more of the PEP syntax
was introduced before the discussion of PEP usage, and then actual syntax
examples given with the PEP usage, but that is just my opinion.

>    Unlike some previous extension proposals [9], and unlike some existing
>    HTTP/1.1 features (Upgrade: and Connection: tokens), extensions are
>    attributes of a resource rather than a server. This means all PEP
>    statements are applied to the single resource mentioned in any HTTP
>    message (though there is a facility to hint at which other resources
>    the same statement applies to).

The above is awkward and a bit out of scope -- I would replace it with

     PEP extensions are attributes of a resource rather than of the
     client, server, or current connection; this is unlike the Upgrade
     and Connection fields of HTTP/1.1, which apply only to the current
     connection, and [which???] extensions in an earlier proposal [9].
     PEP statements apply to the resource indicated by the HTTP message,
     which is generally the requested resource. (However, there is a
     facility to hint at other resources for which the same statement
     applies).

>    A client can wait to piggyback its queries on other HTTP transactions
>    or it can explictly issue an OPTIONS request with its queries.

This would be clearer if you used OPTIONS in the examples (particularly
in the JEPI draft where it improperly uses GET in places it would not be
used in practice).

>    This directive packages together any added header lines and any
>    reprocessing of the message body. Since HTTP/1.1 eliminates many
>    earlier ambiguities about the ordering of headers, we can state
>    categorically that protocol directives must be dispatched in the order
>    they are listed in the Protocol: header. [The Content-Encoding:
>    pipelining mechanism of earlier proposals has been scrapped].

True, but only if the extension does not affect the data type of the
message body.  If it does, that must be indicated via a change in one of:
Content-Type, Content-Encoding, or Transfer-Encoding, depending on how
it is intended to be interpreted.  There are many possibilities in how
to indicate such a change, but something must appear in one of those fields.

>        word             = token | quoted-string
>        token            = 1*<any CHAR except CTLs or tspecials>
>        tspecials        = "(" | ")" | "<" | ">" | "@"
>                         | "," | ";" | ":" | "\" | <">
>                         | "/" | "[" | "]" | "?" | "="
>                         | "{" | "}" | SP  | HT
>        quoted-string    = ( <"> *(qdtext) <"> )
>        qdtext           = <any CHAR except <"> and CTLs but including LWS>

Unless you intend to change the above, they should just reference HTTP/1.1.

>    scope
>           scope is either of "conn" or "origin" ; the default is
>           "origin". It defines which agent must recognize this directive:
>           the immediate recipient or the origin client/server.

Umm, what about a scope of "all"?  PEP cannot be used to express many
cache-related extensions without the notion of a requirement that is
applicable to all recipients.  The same applies to some encryption extensions.
I know you had it before -- what happened to it?

>    500 Class
>           520 Protocol Extension Error
>           521 Protocol Extension Not Implemented
>           522 Protocol Extension Parameters Not Acceptable

Is 522 intended for gateways?  It sounds more like a 4xx response.
The reason-phrase is not sufficient to divine the purpose of each code.

>    [3]    Jim Gettys, et al, "Hypertext Transfer Protocol -- HTTP/1.1".
>           Internet Draft W3 Consortium/MIT, August 1996 (Work in
>           Progress).

Please include the correct reference (and a URL is appropriate for drafts).


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Monday, 19 August 1996 22:52:06 UTC