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

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

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

Scott Lawrence lawrence at agranat.com
Mon Apr 28 10:23:17 EDT 1997


>>>>> "BH" == Robert Herriot <Robert.Herriot at Eng.Sun.COM>:


>> From rdebry at 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?


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.


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


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.


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


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.


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


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       <lawrence at agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/




More information about the Ipp mailing list