Subject: RE: IPP> New IPP Model Document

From: "Turner, Randy" <[email-masked]>
Date: Fri, 29 May 1998 15:06:25 -0700

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: Carl Kugler <[email-masked]>
Date: Fri, 29 May 1998 18:21:02 -0400

> why are we specifying printer-uri/job-uri at all at the IPP protocol level?

Only to allow future deployment of the IPP Model over non-HTTP protocols.

[email-masked] on 05/29/98 03:59:00 PM
Please respond to [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: IPP> New IPP Model Document

Randy,

> This may be a difficult requirement to meet if an IPP implementation is

 ...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
>         > :: In fact, the HTTP request header URI, if persent, takes
> precedence"
>         > 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
>
>

---

From: "Scott Isaacson" <[email-masked]>
Date: Fri, 29 May 1998 16:19:56 -0600

As I recall, 
the only reason that the printer-uri/job-uri attributes are in
protocol at the IPP layer, is because we wanted to be
consistent with possibly future mappings of IPP onto 
protocols other than HTTP where we didn't have
equivalent routing info.  These attributes in the IPP
payload are totally redundant and they are not needed
in the HTTP mapping.

Maybe it was a bad idea to add them, since many
server implementations behind a generic web server
(as Randy points out) will work fine even if it never
even validates the values of these attributes that are
internal to the application/ipp blob.

Scott

>>> Jay Martin <[email-masked]> 05/29 3:51 PM >>>
> snip...

	...jay

---

From: Carl Kugler <[email-masked]>
Date: Fri, 29 May 1998 18:59:28 -0400

> different? (I may have missed some email...)

They certainly will be literally different if the client is talking directly to
the origin server (Request-URI must be an abs_path URI:  Relative) and IPP
mandates Absolute URIs in application/ipp.

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

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,

implementation is

  ...jay

implementation is
takes
the
have
URI.
[email-masked]

---

From: "Scott Isaacson" <[email-masked]>
Date: Fri, 29 May 1998 17:34:39 -0600

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

After TLS negotiation?

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,

implementation is

  ...jay

implementation is
takes
the
have
URI.
[email-masked]

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 29 May 1998 21:43:08 -0700

I think in the case of IPP behind a generic web server, the two headers
are entirely different, and precedence does not apply. I'm pretty sure
it applies in all cases, even a dedicated IPP/HTTP server, but give me
the weekend to mull it over ;)

Randy

-----Original Message-----
From: Jay Martin
To: Turner, Randy
Cc: [email-masked]
Sent: 5/29/98 6:28 PM
Subject: Re: IPP> New IPP Model Document

Randy,

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

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

---

From: Carl Kugler <[email-masked]>
Date: Mon, 1 Jun 1998 16:53:46 -0400

Scott -

Maybe we need to step back and define the requirements before we nail down the
specification.

Consider some high-level scenarios:

1)  IPP over HTTP:   the simplest approach here, I think, would be to let the
Request-URI take precedence.  In this scenario, the IPP embedded target URI
(printer-uri, job-uri, etc.) is essentially meaningless, since any entity in a
position to read it has already been identified as the resource designated to
receive this request by the HTTP Request-URI.  But this scenario (IPP/HTTP)
isn't the reason that the target URI was added to the IPP protocol.   In fact,
we know that IPP/HTTP can work without IPP embedded target URIs.

2) IPP over non-HTTP transport (e.g., IPP over SMTP):  In this scenario, any
entity in a position to read the IPP embedded target URI attributes is
presumably an IPP Object.  Therefore, the addressing of the request to the
appropriate IPP Object is the responsibility of the transport layer (e.g., by
email address).  The IPP embedded target URI is used to identify a resource
relative to the receiving IPP Object (e.g., a Job within the context of a
Printer).  So it is a Relative URI.

3)  IPP Router:  Apparently there are other scenarios involving some kind of
IPP router capable of parsing an IPP request and retransmitting it to the
resource identified by the embedded target URI.  I haven't seen any of these
re-route scenarios, but I think that only by working through some of them will
we come to understand what the real requirements are.  Maybe we need a new IPP
embedded target URI attribute, of Absolute form, to identifiy the destination
IPP Object in a router scenario.
Scenario 1) could be modified to fit the general case of 2).  Then the HTTP
Request-URI would identify a Printer relative to a host, and the IPP embedded
target URI would identify a resource relative to that Printer.

  - Carl

[email-masked] on 05/29/98 05:35:45 PM
Please respond to [email-masked]
To: Carl Kugler/Boulder/IBM@ibmus, [email-masked]
cc:
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

After TLS negotiation?

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,

implementation is

  ...jay

implementation is
takes
the
have
URI.
[email-masked]