Subject: Re: IPP>PRO - comments on your Bob's protocol proposal

From: [email-masked] (Robert Herriot)
Date: Fri, 25 Apr 1997 18:44:17 -0700

You bring up a lot of good issues. Here are my replies.

Bob Herriot

> From [email-masked] 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.

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 28 Apr 1997 10:23:17 -0400

>>>>> "BH" == Robert Herriot <[email-masked]>:

>> to make use of persistent connnections?

BH> Yes, you are right Connection should be there. I'm no expert in HTTP,
BH> so I probably missed a few others.

  'Connection' is used for two things; specifying which other headers
  must be treated as per-hop headers and thus not forwarded or cached,
  and sending the 'close' connection option.

  The 'close' option signals that following this response the
  connection will be closed rather than remain open to be reused.
  This is an escape mechanism to _not_ use persistent connections,
  which is the default in HTTP/1.1.

  Yes, you should require support for it.

>> attributes in some cases and header fields in others.

BH> ... I think that this sort of information should be outside of the
BH> application/IPP because it should be an authentic as possible and
BH> it may come from some lower layer of the transport.

  I think it is a mistake to assume that the lower layer is the more
  authentic information.  It must be assumed that an attacker has
  control of every bit you receive, and any authentication mechanism
  must work despite that.

>> like sending this as a heder vs. as an attribute.

BH> This is some stuff from HTTP that I expected might be used for redirecting
BH> a printer.  I didn't intend this for the Job-URL, though I suppose it
BH> could work that way.

  Redirecting would be correct - attempting to overload it with any
  other use would probably cause problems later.

>> says. My same comment applies about using headers vs. attributes.

BH> No, I intended it to hold the Document-name in SendJob.  It seems
BH> easier to have the document-name in the Content-Location header than to
BH> create an application/IPP for just the document-name. The Content-location
BH> intializes the document-name attribute which is a set of names.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/