Subject: Re: IPP> Identifying jobs in requests

From: James Walker <[email-masked]>
Date: Wed, 10 Jun 1998 07:45:48 -0500

Randy Turner wrote:
> 
> Thanks for the synopsis. It appears that the administrative capability to
> filter IPP traffic via proxies is a feature that Keith thinks should be
> provided by IPP. If this is the only key issue holding up our spec, then I
> would like to suggest that we look into a new method (such as PRINT), and
> avoid (for now) the issue of new schemes and/or port numbers for IPP. It's
> the "short path" in my opinion to getting us going again.
> 
> ...

I also got the impression from comments made in this discussion that
there was some advantage for a user to be able to look at an URL and
somehow "know" that it was an IPP thing rather than just some web
page.  Thus, Larry's ipp: scheme idea (which gets translated at the
client side to http://<server>:<ipp port>/) seems attractive.

Personally, I think that both of these ideas provide useful
functionality, and we should consider both of them.  That is,
use the ipp: scheme (which the client translates to http:),
and use a new PRINT method.

one man's thoughts...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 10 Jun 1998 08:26:20 PDT

Actually, I realize that if TLS is mandatory for IPP, then
"ipp://host.dom/path" gets turned into "https://host.dom:432/path",
i.e., assuming a secure transmission.

Larry
--
http://www.parc.xerox.com/masinter

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 10 Jun 1998 09:11:49 PDT

>i.e., assuming a secure transmission.

Larry,

We will discuss this with Keith. He thinks otherwise.

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]