Subject: RE: RE: IPP> New IPP Model Document

From: "Turner, Randy" <[email-masked]>
Date: Fri, 29 May 1998 16:56:44 -0700

It is becoming clear to me that the two URI(URLs) actually mean
different things, and that each URI should be handled by different
pieces of the system; the HTTP header should be handled by the outer
HTTP processing code, while the inner URI should be handled by the core
IPP code. Its almost like the HTTP URI is really the transport URI, and
the IPP URI really points to the IPP object to which we are
communicating (the application layer object).

Randy

	-----Original Message-----
	From:	Scott Isaacson [SMTP:[email-masked]]
	Sent:	Friday, May 29, 1998 4:35 PM
	To:	[email-masked]; [email-masked]
	Subject:	Re: RE: IPP> New IPP Model Document

	Carl,

	You provide good examples of why two URLs might refer to the
same IPP object yet might be literally different (this gets back to the
classical problems with equality - syntactically, semantically, instance
vs class, type vs value, etc).   Do we need to put any of them in the
document as examples?

	Can we live with the fairly simple statement that is in the
document:
	" 2. Even though these two URLs might not be literally identical
(one being relative and the other being absolute), they must both
reference the same IPP object."
	or is the statement too simple?

	I also think that most of the text that I added to the model
document on this subject should be moved to the encoding and transport
document.  The model document should not care about all of the reasons
why 2 HTTP URLs might not be identical and yet refer to the "same"
resource.  What do you think?

	Scott

	>>> Carl Kugler <[email-masked]> 05/29 4:59 PM >>>
	Speculation:  they might also be different:

	After TLS negotiation?

	Where the URIs are semantically the same but syntactically
different, e.g.:
	 - Absolute vs. Relative
	 - host.domain vs dotted-ip
	 - Default port specified vs. port omitted
	 - UPPERCASE/lowercase in hostname
	 - URI translation using equivalent escape codes

	After an HTTP redirect handled automatically by an HTTP layer in
the client
	stack that doesn't know about IPP?

	Maybe an HTTP proxy server handles a redirect invisibly to the
client?

	[email-masked] on 05/29/98 04:13:56 PM
	Please respond to [email-masked] 
	To: [email-masked] 
	cc: [email-masked] 
	Subject: RE: IPP> New IPP Model Document

	Absolutely, I see the advantage of having the IPP information
take
	precedence, I'm just not sure of the impact of having the two
headers
	(HTTP and IPP-body) be different, and actually getting this to
work in a
	CGI/NSAPI/ISAPI-based implementation.

	The generic web server will dispatch to the HTTP
header-specified URI
	(I'm assuming, someone correct me if this is not the case). Once
this
	dispatch occurs, the target in the HTTP header better be able to
handle
	whatever is coming in the application/ipp body part. In this
scenario,
	its too late to apply any precedence.

	Has someone identified a case where the two headers have to be
	different? (I may have missed some email...)

	Randy

	 -----Original Message-----
	 From: Jay Martin [SMTP:[email-masked]] 
	 Sent: Friday, May 29, 1998 2:51 PM
	 To: Turner, Randy
	 Cc: [email-masked]; Puru Bish
	 Subject: Re: IPP> New IPP Model Document

	 Randy,

	 > This may be a difficult requirement to meet if an IPP
	implementation is
	 > built as an extension to a generic web server (like Apache).

	 Are you sure about this?  I mean, I can see you point to
	 a certain extent, but wouldn't it be advantageous for an
	 IPP server implemented as a front-end on a generic platform
	 to be used as a multiplexor to several Printers and Jobs?

	 On the other hand, if the HTTP request header takes precedent,
	 then why are we specifying printer-uri/job-uri at all at the
	 IPP protocol level?  Aren't we asking for trouble when the
	 HTTP request header and the corresponding IPP attributes don't
	 match (with regard to interoperability)?

	  ...jay

----------------------------------------------------------------------
	 --  JK Martin               |  Email:   [email-masked] 
	--
	 --  Underscore, Inc.        |  Voice:   (603) 889-7000
	--
	 --  41C Sagamore Park Road  |  Fax:     (603) 889-2699
	--
	 --  Hudson, NH 03051-4915   |  Web:
	http://www.underscore.com   --

----------------------------------------------------------------------

	 Turner, Randy wrote:
	 >
	 > This may be a difficult requirement to meet if an IPP
	implementation is
	 > built as an extension to a generic web server (like Apache).
	 >
	 > Randy
	 >
	 >         -----Original Message-----
	 >         From:   Jay Martin [SMTP:[email-masked]] 
	 >         Sent:   Friday, May 29, 1998 2:34 PM
	 >         To:     [email-masked] 
	 >         Cc:     Puru Bish
	 >         Subject:        Re: IPP> New IPP Model Document
	 >
	 >         After thinking about this, I tend to agree with
Puru's
	 >         statement:
	 >
	 >         >From "Tom Hastings"
	 >         >
	 >         > :: In fact, the HTTP request header URI, if
persent,
	takes
	 > precedence"
	 >         > (over printer-uri/job-uri operation attributes).
	 >         >
	 >         > I think it should  be the other way around. I feel
	the
	 >         > printer-uri/job-uri, supplied by IPP client, should
	have
	 > higher
	 >         > precedence to an IPP server than the HTTP header
	URI.
	 >                 ...jay
	
----------------------------------------------------------------------
	 >         --  JK Martin               |  Email:
	[email-masked] 
	 > --
	 >         --  Underscore, Inc.        |  Voice:   (603)
889-7000
	 > --
	 >         --  41C Sagamore Park Road  |  Fax:     (603)
889-2699
	 > --
	 >         --  Hudson, NH 03051-4915   |  Web:
	 > http://www.underscore.com   --
	 >
	 >
	
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Fri, 29 May 1998 21:28:36 -0400

Randy,

> communicating (the application layer object).

Ok, then I guess we're back to Puru's basic inquiry
revolving around precedence between the two URLs.

Based on your above statement, it sounds like we must
have NO precedence whatsoever, right?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------