Maybe we need to step back and define the requirements before we nail d=
own the
specification.
Consider some high-level scenarios:
1) IPP over HTTP: the simplest approach here, I think, would be to l=
et the
Request-URI take precedence. In this scenario, the IPP embedded target=
URI
(printer-uri, job-uri, etc.) is essentially meaningless, since any enti=
ty in a
position to read it has already been identified as the resource designa=
ted to
receive this request by the HTTP Request-URI. But this scenario (IPP/H=
TTP)
isn't the reason that the target URI was added to the IPP protocol. I=
n 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 reso=
urce
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 ki=
nd of
IPP router capable of parsing an IPP request and retransmitting it to t=
he
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 th=
em 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 desti=
nation
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 em=
bedded
target URI would identify a resource relative to that Printer.
- Carl
SISAACSON@novell.com on 05/29/98 05:35:45 PM
Please respond to SISAACSON@novell.com
To: Carl Kugler/Boulder/IBM@ibmus, ipp@pwg.org
cc:
Subject: Re: RE: IPP> New IPP Model Document
Carl,
You provide good examples of why two URLs might refer to the same IPP o=
bject
yet might be literally different (this gets back to the classical probl=
ems with
equality - syntactically, semantically, instance vs class, type vs valu=
e,
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 b=
eing
relative and the other being absolute), they must both reference the sa=
me IPP
object."
or is the statement too simple?
I also think that most of the text that I added to the model document o=
n this
subject should be moved to the encoding and transport document. The mo=
del
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 <kugler@us.ibm.com> 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 cl=
ient
stack that doesn't know about IPP?
Maybe an HTTP proxy server handles a redirect invisibly to the client?
owner-ipp@pwg.org on 05/29/98 04:13:56 PM
Please respond to owner-ipp@pwg.org
To: jkm@underscore.com
cc: ipp@pwg.org
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:jkm@underscore.com]
Sent: Friday, May 29, 1998 2:51 PM
To: Turner, Randy
Cc: ipp@pwg.org; 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: jkm@underscore.com
-- -- 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:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > 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: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ----------------------------------------------------------------------
=