Subject: IPP> Host to device

From: Roger K Debry <[email-masked]>
Date: Fri, 3 Apr 1998 15:48:32 -0500

I have read both Randy's TCP/IP mapping document and Don's TIP/SI
mapping document.  I have to admit that I haven't spent a lot of time trying
to write down a detailed proposal, but I make the following observations:

A lot of work went into TIP/SI to develop a host to device protocol which
was transport independent. In particular, it runs on both TCP/IP and a
IEEE 1284 parallel port.  It outlines all of the rules for handling out of band
communications, continuation, and acknowledgements.

A lot of work has also gone into developing a model for submitting and
anaging print jobs in IPP. The model reflects current thinking in this area
and has taken into account parallel work on Printer and Job MIB.

Although Don would probably not approve, one could take the TIP/SI
packet structure (including the TIP/SI packet header), as defined
today but with new commands (below),  and carry an IPP payload with it.
Now we don't have to re-invent flow control, data stream level acks,, etc.

The TIP/SI LU becomes the IPP Job ID
The TIP/SI payload becomes the IPP message
The IPP commands are used in TIP/SI as shown:

o Print-Job would not be used in host-to-device
o Create-Job replaces the TIP/SI Start job command
o Validate-Job would not be used in host-to-device
o Get-Printer replaces the TIP/SI RDC and RIC commands
o Get-Jobs replaces the TIP/SI JC-QJC command
o Send Document and Send URI go to the LU

A sample job submission flow would look like:

1. Connect
2. Start Session (as is in TIP/SI)
3. Create-Job (response is IPP job ID)
4. Send Document (destination bit = LU,
     LU# = IPP Job ID)
5. End-Job (as is in TIP/SI)
6. End-Session (as is in TIP/SI)
7. Disconnect

This is very high level and obviously not completely thought
through, but it seems to me that we ought to be able to leverage
al ot of good, hard work and marry these two ideas together to
come up with a version of IPP for host-to-device that meets all
of Paul Moore's requirements. Thoughts???

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 3 Apr 1998 13:16:31 -0800

One key point to remember is, is that I don't think we need to be taking
TIPSI and modifying it. If you don't use it as is, then you are not
compliant with TIPSI, and I think a lot of the benefit of using TIPSI is
the fact that it exists as an interoperable standard specification.

My next draft which I am working on adds client "pull" functionality and
cleans up the transport header. I hope to have it out by tomorrow, and I
will have copies (hardcopy) at the meeting.

Randy

	-----Original Message-----
	From:	Roger K Debry [SMTP:[email-masked]]
	Sent:	Friday, April 03, 1998 12:49 PM
	To:	[email-masked]
	Subject:	IPP> Host to device

	I have read both Randy's TCP/IP mapping document and Don's
TIP/SI
	mapping document.  I have to admit that I haven't spent a lot of
time trying
	to write down a detailed proposal, but I make the following
observations:

	A lot of work went into TIP/SI to develop a host to device
protocol which
	was transport independent. In particular, it runs on both TCP/IP
and a
	IEEE 1284 parallel port.  It outlines all of the rules for
handling out of band
	communications, continuation, and acknowledgements.

	A lot of work has also gone into developing a model for
submitting and
	anaging print jobs in IPP. The model reflects current thinking
in this area
	and has taken into account parallel work on Printer and Job MIB.

	Although Don would probably not approve, one could take the
TIP/SI
	packet structure (including the TIP/SI packet header), as
defined
	today but with new commands (below),  and carry an IPP payload
with it.
	Now we don't have to re-invent flow control, data stream level
acks,, etc.

	1. Connect

	Roger K deBry

---

From: [email-masked]
Date: Fri, 3 Apr 1998 16:22:22 -0500

Randy:

My biggest concern is that your proposal is TCP/IP only.  Is does not solve
the problem for printers connected to servers via:

- Parallel
- Serial
- USB
- 1394
- IPX/SPX
- AppleTalk
- DLC/LLC
- etc., etc., etc.

If I'm going to use TCP/IP then I might as well go ahead with the HTTP
based implementation.  You don't provide more status and control or
anything else that really buys me anything other than a slightly lighter
transport.  It's just not work the trouble for the return on investment.

Don

**********************************************
* Don Wright                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: "Gordon, Charles" <[email-masked]>
Date: Fri, 3 Apr 1998 16:56:52 -0500

Given that IPP is the Internet Printing Protocol, do we really need to
support anything else besides TCP/IP?  Is the IPP working group even
mandated to worry about non TCP/IP environments?

					--- Charles

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, April 03, 1998 4:22 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: IPP> Host to device
> 
> 
> Randy:
>

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 3 Apr 1998 14:19:22 -0800

I'm kinda in Jay's camp, I'm not sure anymore what the desires of the WG
are anymore with regards to what we were thinking about....looks like
another agenda item for the meeting.

Randy

	-----Original Message-----
	From:	Jay Martin [SMTP:[email-masked]]
	Sent:	Friday, April 03, 1998 2:15 PM
	To:	[email-masked]
	Cc:	[email-masked]; [email-masked];
[email-masked]
	Subject:	Re: IPP> Host to device

	I was really hoping the IPP WG would be constrained to *only*
	handling print requests over the "Internet", and that the more
	functional host-to-device protocol would be addressed via a
	different project within the PWG (or WG under the IETF, if
that's
	preferred).

	If I read Roger's approach correctly, it would appear that
TIP/SI
	is being used as nothing more than a thin wrapper around IPP in
	exactly the same manner as the HTTP approach.  This is highly
	undesirable, IMHO.

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

	[email-masked] wrote:
	> 
	> Charles:
	> 
	> TCP/IP is the inbound transport from the client to the server.
We are
	> talking here about the server to the printer.  That connection
could be
	> anything.  This discussion is certainly appropriate for the
Printer Working
	> Group chartered IPP group.  While the IETF can pretend that
only TCP/IP is
	> used for communication, the reality is that most printers are
not connected
	> to computers using TCP/IP.
	> 
	> To:   Don Wright@Lexmark,
[email-masked]
	> cc:   [email-masked],
	>       [email-masked]
	> bcc:
	> > My biggest concern is that your proposal is TCP/IP only.  Is
does not
	> > solve
	> > anything else that really buys me anything other than a
slightly
	> > lighter

---

From: Paul Moore <[email-masked]>
Date: Fri, 3 Apr 1998 14:21:34 -0800

Good point - it would look very odd to have IPP for USB. 

Also odd would be to have two IPP implmentations on TCP/IP - HTTP and direct
TCP/IP.

In retrospect the correct thing to have done was to produce a mapping of
TIP/SI onto HTTP. Ie. HTTP is just another transport layer. 

> From:	Gordon, Charles [SMTP:[email-masked]]
> Sent:	Friday, April 03, 1998 1:57 PM
> To:	[email-masked]'; [email-masked]

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 3 Apr 1998 16:16:48 PST

Charles,

You are right that if we see this only from an IETF perspective,
we do not need to care about all the other transfer protocols.
However, it is of general interest to members of the PWG to also
look for solutions that go beyond the IETF scope.

I expect that when we write up a solution for extending the IPP
within the IETF to cover IPP notifications, such a proposal
will be limited to the TCP/IP case.

Carl-Uno

>> transport.  It's just not work the trouble for the return on
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]

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 3 Apr 1998 16:16:48 PST

Charles,

Carl-Uno

Carl-Uno Manros

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Fri, 3 Apr 1998 20:23:42 PST

Hi folks,                                          Friday (3 April 1998)

I can't resist shooting these ducks in a barrel.  The IETF does NOT only
publish protocols over TCP/IP.  For ten years there have been IETF
standard mappings for SNMP (their ONLY 'standards track' net management
protocol) over six different transports.  The change log of the latest
revision of HTTP (draft-ietf-http-v11-spec-rev-03.txt, 13 March 1998)
shows updates to REMOVE any impression that TCP/IP should be the only
transport.

Mapping IPP over multiple non-Internet transports is entirely suitable
for an IETF 'standards track' document.  The IETF gave up on Internet
suite everywhere a LONG time ago.

Cheers,
- Ira McDonald (High North)

>----------------------------------------------------------------------<
>Date: Fri, 3 Apr 1998 16:16:48 PST
>To: "Gordon, Charles" <[email-masked]>, [email-masked]
>From: Carl-Uno Manros <[email-masked]>
>Cc: [email-masked], [email-masked]
>
>Charles,
>
>----------------------------------------------------------------------<

---

From: "Turner, Randy" <[email-masked]>
Date: Fri, 3 Apr 1998 20:27:22 -0800

-----Original Message-----
	From:	[email-masked]
[SMTP:[email-masked]]
	Sent:	Friday, April 03, 1998 8:24 PM
	To:	[email-masked]
	Subject:	RE: IPP> Host to device

	..snip..

	Mapping IPP over multiple non-Internet transports is entirely
suitable
	for an IETF 'standards track' document.  The IETF gave up on
Internet
	suite everywhere a LONG time ago.

	<RT>
	There is still a presence within the IESG, and at least two on
the IAB that have not been "assimilated" into other transports. They are
still IP bigots (kinda like myself). To wit, Keith Moore, during the
Internet FAX WG meeting this meeting was wearing a T-shirt that had only
one phrase on it..."IP: necessary and sufficient".

	One interesting side note, I noticed he was also running "Linux"
on his laptop, not Win95 like most everyone else was running....hmmm....

	Randy

	Cheers,

does not
slightly

---

From: Harry Lewis <[email-masked]>
Date: Sat, 4 Apr 1998 02:18:51 -0500

I disagree that it would be odd to see IPP over other transports. Why would
that be any less desirable than, say, TIPSI over USB? What is odd, to me, is
for a standards group to invent one protocol and not deploy it (TIPSI), then,
later, invent another (IPP) and try to limit (rather than enhance) it, trying
to substitute the (now) older solution in it's place. Roger's observation is
that, what makes TIPSI transport independent, is the packet structure, with
continuation flag, ACKs and the ability to interleave commands (like CANCEL),
not the command/query definitions themselves (which have been superseded by
IPP). Randy is evolving a specific mapping to TCP/IP which addresses these
issues as well (chunking, separate channel...). I don't see what is wrong with
either approach.

Harry Lewis - IBM Printing Systems

[email-masked] on 04/03/98 03:25:05 PM
Please respond to [email-masked]
To: [email-masked], [email-masked], [email-masked]
cc: [email-masked], Roger K Debry/Boulder/IBM@ibmus
Subject: RE: IPP> Host to device

---

From: "Turner, Randy" <[email-masked]>
Date: Sat, 4 Apr 1998 04:50:39 -0800

Once I get a draft in more or less complete form, I think you will find
the implementation burden to be far less than IPP over HTTP. Once we
start actually doing interop with a variety of HTTP servers or clients,
I think we will see that in order to properly interoperate in the HTTP
world (HTTP 1.1), that we will have to have several iterations of
interop to get things even close to handling the variety of HTTP
client/server environments that exist. I am mainly concerned with issues
like:

	1. The fact that Apache is the most widely used and deployed
HTTP server in the market, and it doesn't support chunking through the
CGI interface.
      2. Realizing that there will be problems using things like
"chunking" to currently deployed hybrid HTTP 1.0/1.1 servers.
	3. Tunneling issues with security, through HTTP proxies.
      4.  HTTP proxy response caching.

There are other issues with proper handling of HTTP headers and status
codes that I won't go into in this note. None of the above issues are
issues for my transport proposal. In my opinion, the burden of
implementation is quite high with HTTP, much higher than what is implied
by my proposal. I think the burden is high whether you roll your own
HTTP or license the code from an outside vendor. Not that I'm trashing
our decision to use it as a transport. I still think it is viable, but
it is a very non-trivial design issue for both IPP clients and servers.

Randy

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Friday, April 03, 1998 1:22 PM
	To:	[email-masked]
	Cc:	[email-masked]; [email-masked]
	Subject:	RE: IPP> Host to device

	Randy:

does not solve

	- Parallel
	- Serial
	- USB
	- 1394
	- IPX/SPX
	- AppleTalk
	- DLC/LLC
	- etc., etc., etc.

	If I'm going to use TCP/IP then I might as well go ahead with
the HTTP
	based implementation.  You don't provide more status and control
or
	anything else that really buys me anything other than a slightly
lighter
	transport.  It's just not work the trouble for the return on
investment.

	Don

---

From: Paul Moore <[email-masked]>
Date: Mon, 6 Apr 1998 10:43:03 -0700

I meant 'odd' in a very specific way. IPP is INTERNET Printng Protocol - USB
is not normally considered as an Internet transport. The  Internet is, after
all, a TCP/IP network.

I do not see anybody trying to LIMIT IPP. All I see are people (including
me) pointing out its limitiations - this is not the same thing at all. 

> From:	Harry Lewis [SMTP:[email-masked]]
> Sent:	Friday, April 03, 1998 11:19 PM
> To:	[email-masked]
> Cc:	Roger K Debry; [email-masked]; [email-masked];
> [email-masked]

---

From: Harry Lewis <[email-masked]>
Date: Mon, 6 Apr 1998 17:31:06 -0400

In reverse order...

>me) pointing out its limitations - this is not the same thing at all.

Agree. Poor phrasing on my part. Your list of limitations has formed an
especially good basis for discussing enhancements.

>I meant 'odd' in a very specific way. IPP is INTERNET Printing Protocol - USB

Maybe I've allowed myself to become too hopeful regarding our IPP model

---

From: Harry Lewis <[email-masked]>
Date: Mon, 6 Apr 1998 18:09:33 -0400

Guess I ran out of quarters or something. My last post on this topic should
have read...

>I view this as an abstract set of print operations and attributes which
>can be mapped to nearly any transport protocol, the first being HTTP - thus
>making this the Internet Printing Protocol. I expected future mappings,
>to TCP/IP for example, and had hoped that printing would begin to look and
>feel quite similar throughout the distributed environment. Peer-to-Peer may
>be a different story, as you point out.

-- Forwarded by Harry Lewis--

[email-masked] on 04/06/98 03:26:43 PM
Please respond to [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked],
[email-masked], Roger K Debry/Boulder/IBM@ibmus
Subject: RE: IPP> Host to device

In reverse order...