I have some questions on some entries in the tables in section "7 Encoding
and Transport" of the IPP/1.1 Implementer's Guide, dated 7/17/2001. I hear
that the IIG is in the middle of a revision, so I think this is a good time
for my issues. Please forgive me if I am getting too picky here--just let
me know and I'll shut up!
Specifically:
- "Connection" header field. Both the Request/Server and Response/Client
entries are "must". However, for clients that do not wish to have a
persistent connection (that is, that included "Connection: close" on the
request), or for servers that do not support persistent connections (that
is, that include "Connection: close" on every response), there is no need
to parse the incoming Connection field. Should these entries be "must-if",
with a description that the client or server must support this header field
only if they are expecting a persistent connection?
- "Content-Encoding" header field. The Response/Server entry is "must",
indicating that the server must include the Content-Encoding header field.
However, RFC 2616 says that a Content-Encoding header field should only be
used when the encoding is not "identity". Should this entry be a
"must-if", saying that Content-Encoding must be included if the encoding is
not "identity"?
- "Content-Encoding" header field. The Response/Client entry is "must".
But if a client sends the "Accept-Encoding" header such that only one
encoding is acceptable (e.g. "Accept-Encoding: identity"), there does not
seem to be a great need to look at the "Content-Encoding" returned in the
response. A correctly-written server will either give the client the
encoding it wants, or fail the request with 406 "Not acceptable". A
less-than-correctly-written server might give the client an encoding it
doesn't understand, but spending time to check the Content-Encoding header
or simply trying to parse the IPP and failing will both pretty much end up
with the client putting up some sort of "Unreadable response" error.
Should this entry be a "must-if", saying that Content-Encoding is optional
for clients that have used the "Accept-Encoding" header to indicate support
for only one encoding, and mandatory otherwise?
- "Content-Type" header field. The Response/Client entry is "must". But
it seems as if any response with HTTP 200 OK will always have
"Content-Type: application/ipp" (since the Response/Server entry is a
"must"), and all other HTTP responses won't. So does the client really
need to check this? For example, if a client sent an IPP request, got back
an HTTP 200 OK, but there was no Content-Type field (or a Content-Type
other than application/ipp), should we really force the client to consider
this as a bad response, or should we give the client the option to go ahead
and try to parse the response as IPP anyway? Should this entry be a "may"?
- "Accept" header field. The Server entry is "must". By the same
argument, should this be "may"? (That is, do we want to *force* servers to
reject requests that come in on port 631 but that have an Accept value
other than application/ipp?)
It is possible that some of my issues have to do with what exactly the
document means when it says a client/server must "support" a header. If
the header can have only one value, does "supporting" it mean that the
recipient must verify that it is there with the right value? Or does it
only mean the recipient must tolerate the existence of the header?
Comments?
Dennis Carney
IBM Printing Systems (303)924-0565
This archive was generated by hypermail 2b29 : Wed Aug 15 2001 - 19:53:40 EDT