Bob Herriot
> From rdebry@us.ibm.com Fri Apr 25 12:57:44 1997
> 1) You suggest that we don't use the connection general-header.
> Isn't this there to provide persistent connections? Mightn't we want
> to make use of persistent connnections?
Yes, you are right Connection should be there. I'm no expert in HTTP,
so I probably missed a few others.
> 3) How is the From request-header different from the Job-originator
> attribute? Are they identical? I don't feel entirely comfortable using
> attributes in some cases and header fields in others.
I am assuming the the job-originator (now job-originating-user) and
job-originating-host in the model are set from the From header in the
protocol, though job-originating-host may be the mail host instead of the
client's host.
I think that this sort of information should be outside of the application/IPP
because it should be an authentic as possible and it may come from some
lower layer of the transport.
For the GetAttributes operation job-originating-user and -host are the means
of retrieving this information.
>
> 4) You say that the Location response header specifies the URL
> for the client to use? Is this the Job-URL? Again, I'm not sure I
> like sending this as a heder vs. as an attribute.
This is some stuff from HTTP that I expected might be used for redirecting
a printer. I didn't intend this for the Job-URL, though I suppose it
could work that way.
>
> 5) If we don't use the Accept-encoding request header, do we need
> the Content-encoding enitity header in the response?
I would expect the Content-encoding header to be present in a response only
if the entity-body were encoded. By the way, HTTP says that if there is
no Accept-encoding request header, the client will accept any encoding.
Clients might want to say "Accept-encoding:" to indicate that it doesn't
accept any encodings.
>
> 6) Is the Content-Location header in the entity-header of the response
> the Job-URl to be used in SendJob? That's what I think your description
> says. My same comment applies about using headers vs. attributes.
No, I intended it to hold the Document-name in SendJob. It seems
easier to have the document-name in the Content-Location header than to
create an application/IPP for just the document-name. The Content-location
intializes the document-name attribute which is a set of names.
>
> 7) You say that if the entity-body for SendJob is absent the job is aborted.
> In print by reference, where does the URL for the document to be printed
> go? In this case is there no SendJob request at all?
We could also use Content-Location but with no entity-body, though I think
that I have seen other solutions.
>
> 8) I don't see any reason to have attributes take up more than one line.
I agree. But there are still potential long line issues that an
implementation has to deal with.
>
> 9) You say that an application/IPP entity-body contains all IPP except
> four attributes. Again, I'd prefer to see attributes as consistently sent
> as attributes and not as header fields in
Three of these attributes, job-originating-user, job-originating-host and
document-name I have already discussed my reasoning. The last one is
user-locale. The code-set parameter needs to be outside the application/IPP
so that the program knows how to intepret the data in the entity-body. The
language should also be outside because it may apply to the outer layer, e.g.
in the language of the Reason-Phrase.
>
> 10) You suggest that the first attribute in the application/IPP entity
> identify it's type. Now you've got something that's not an attribute
> as an attribute. I would prefer to define a header field in the mime
> (since I assume we have the freedom to do so) that defines the
> operation - like the http request - line. Then attributes are just
> attributes, there isn't a new funny attribute we use for something else.
Yes, HTTP has a mechanism for adding entity-headers and that is what this
is. So, I agree, this should be an entity-header.
What about the object-type? Should that be removed as redundant, or should
it be an entity-header too?
>
> 11) Could you show a "chunked" example?
In the next edition.
>
>