Re: draft-ietf-http-pep-02

>>  If it does [affect the body], 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.
> 
> Must? There are lines that should be drawn around MIME influence in this  
> protocol. I have an open mind, all the way up to forbidding body-rewriting  
> (see above), but HTTP is a sovereign protocol which can define its own  
> extensions -- extensions which cannot be represented for MIME, anyway. Of  
> course, I can see that the MIME community might want to adopt parts of PEP,  
> too...

I am not referring to MIME -- I am referring to section 7.2.1 of HTTP/1.1,
which is quite explicit about how to determine the data type transferred.

> Another way to placate this need is to put in a blanket "pep" C-E: indicating
> that critical content modification was done by pep extensions.

Yes, that is one way to do it, assuming you don't allow extensions to be
interleaved with normal encodings.

>> [references to grammar rules]
> 
> Roy! It says right above that section: these rules are copied from 2.2 of  
> HTTP/1.1. Grant the reader a *little* mercy in tracing back every reference in
> a spec... In any case, the spirit of this section is to normatively refer to  
> 1.1.

I saw it -- it is a C-style comment (odd in itself) above the definition
of bag, which BTW was removed from the HTTP/1.1 spec.  The reason I mention it
is that other specs (e.g. MIME) only define a BNF item when they intend
to change it, so that only those aspects of the main protocol (HTTP in our
case, 822 for MIME) are highlighted by the updating spec.  Therefore, I think
it is less readable to define things that you don't intend to change.

>>  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?
> 
> The "route" scope used to apply to all agents that handled a message; when  
> some of us gamed it out, it was hard to imagine route extensions that weren't
> a-series-of-successive-connection-extensions, like a row of dominos. The  

The difference is that route placed a requirement on successive connections,
whereas conn only places the requirement on this connection.  If the
requirement has anything to do with security or robustness of the transport
path, then conn just isn't sufficient to express the requirement.

> 522 was imagined more on the basis of "hmm... you bumped into a server  
> implementation limit -- yes, the spec allows you to ask me to do 8192-bit  
> signatures, but it's my fault I can't accept above 256-bits" -- or perhaps  
> something more temporary. Basically: a 423 indicates parameters bad prima  
> facie (a string in place of a number), and 522 indicates run-time errors.  

Okay -- it just needs the explanation then.


 ...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 Wednesday, 21 August 1996 22:56:08 UTC