Re: draft-ietf-http-pep-02

Thanks to Roy for his comments -- quick reaction time! -- here are some of my  
public responses...

I have selected some of Roy's comments in > sections.

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

Fundamentally, this has to do with differing purposes in drafting. This  
go-round is explicitly a discussion draft about "the extension problem" and  
less a formal specification in the form of language amending 1.x (like  
previous drafts, which did cover this arcana).

The underlying question behind this is, then: "should extensions affect the  
interpretation of HTTP content or only HTTP protocol features?". Namely, it is  
in our power to say we *only* want extension to message headers, but  
encryption, say, should be done the MOSS/MIME way and not to let a PEP  
extension rejigger content bytes.

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

Cool. The typewriter font in the HTML makes it clear anyway. This and several  
other minor edits have been applied inW3C WD and IETF I-D format HTML and can  
be reached from our Technical Reports page:  
http://www.w3.org/pub/WWW/TR/WD-http-pep.

I have also incorporated rewording about previous proposals:

]  	Protocol extensions are attributes of a resource
]  	rather than an entire server or connection, which
]  	was the model in 1.1's Connection and Upgrade
]  	fields, and in previous extension proposals [9].
]  	This means each PEP statement is applied to the
]  	single resource mentioned in an HTTP message
]  	(though there is a facility to hint at which
]  	other resources the same statement applies for).

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

1) the JEPI project is being deployed atop 1.0 products, essentially, and can  
not rely on OPTIONS 2) From my reading the JEPI document uses GET and POST  
correctly; detailed feedback is appreciated. In section 10, a query is  
piggybacked on a GET, but could use OPTIONS if available.

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

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.

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

>  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  
difference between route and conn is in proxy handling of optional extensions:  
conn/opt means strip always but route/opt means strip if necessary, but not  
by default. route/req is a superset of conn/req. I admit, I haven't thought  
much about caching scenarios -- but keep in mind one of my goals for this is  
to make PEP much simpler though this review cycle.

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

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.  
Again, though, I'm quite open to rethinking the error list.

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

The urls and so on are linked from the HTML versions cited above.

Rohit
---
Rohit Khare -- World Wide Web Consortium -- Technical Staff
w: 617/253-5884  --   f: 617/258-5999   --  h: 617/491-5030
NE43-354,  MIT LCS,  545 Tech Square,  Cambridge,  MA 02139

Received on Tuesday, 20 August 1996 10:56:16 UTC