Subject: Re: IPP> Why must IPP be transport-independent?

From: Harry Lewis <[email-masked]>
Date: Thu, 4 Jun 1998 15:48:43 -0400

Unfortunate, I guess, that the charter ever made reference to a Universal
Standard for Printing...  http://www.ietf.org/html.charters/ipp-charter.html

Harry Lewis - IBM Printing Systems

[email-masked] on 06/04/98 12:34:54 PM
Please respond to [email-masked]
To: [email-masked]
cc:
Subject: IPP> Why must IPP be transport-independent?

After reading Paul Moore's posting (below), it appears
that we are digger ourselves a deeper and deeper hole
to fall into.

Must IPP be transport-independent?

I say "No".  IPP stands for "Internet Printing Protocol",
not something like "Generic Printing Protocol", or "Universal
Printing Protocol".  It was designed for use on the Internet.

Sure, there are some in the IPP WG who believe IPP can
and *should* become the single, all-encompassing printing
protocol for use in almost any environment.

I (and others) say "hogwash".  Microsoft and Northlake Software
have done a good job in delineating areas in which the IPP
design falls very short in providing the kind of session-
oriented protocol to achieve the kinds of capabilities that
already exist in TIP/SI, CPAP and others.

If HTTP is going to be the first and primary reference
implementation of IPP (damn the nay-sayers...), then why
can't we just tie IPP onto HTTP (semantics, syntax et al)
and be done with it?

Let the SDP project deal with other non-HTTP-oriented
requirements.  We'll just strive to make the mapping
from IPP to SDP as easy and painless as possible.

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

Paul Moore wrote:
>
>         It seem to me that the fundamental question comes down to - should
> the IPP protocol form, transmit and use information that is specific to the
> underlying transport.
>
>         We have chosen to use URI as our way of identifying endpoints. The
> assumptions we make about these URIs (there actual syntax is irrelevant)
> are:-
>         a) an agent knows how to form them
>         b) the only thing an agent may do with a URI it receives to it is to
> pass it to its underlying transport. This means that the creator of the URI
> MUST use the same URI forming convention as that which will be used by the
> receivers transport stack (ie. this is not a private issue for a given
> implementation). It also means that the receiver may not look at the URI to
> infer any deeper meaning (because that is a private issue for the sending
> implementation).
>         This last restriction made us invent job-id. We moved to explicitly
> stating in IPP the way of identifying an endpoint.
>         The real problem is that we end up with leakage from the transport
> up into the IPP layer. I cannot blindly forward requests from
> IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change
> them on the fly.
>         There is another problem that assumpion b causes. It assumes that a
> printer knows how to form an address (URI) that makes sense in the clients
> transport stack. This is true for HTTP but not true (or certainly
> non-trivial) for other transports.
>
>         I would propose that we use an adressing scheme that corresponds to
> the transport endpoint only. We then specifiy in IPP the ways of identifying
> the logical object that we wish to talk to (printer-ID, Job-ID,...).

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 4 Jun 1998 13:19:44 PDT

>Printing Protocol".  It was designed for use on the Internet.

Harry,

I think I start agreeing with you on this one. My recollection is that we
got this as part of our discussion to use a MIME part for the encoding. 
MIME purists have stated that all MIME types MUST be transport independent.

I think that having an object that can be mapped to another transport has
its virtues, but I was never convinced that it would ever make sense to
actually send the "application/ipp" object over email. Alternative
transports that make sense to me are things like the emerging HTTP-NG
protocol, and that is most likely able to handle URLs the same way as HTTP
does today.

If somebody REALLY wants to send "application/ipp" over email, then they
would need to have an email address in the place where we are using the
HTTP URIs anyway, and I expect that such a mailbox would be dedicated to
the IPP printer and know what to do with messages it receives. In short,
new transport, new addressing scheme.

In summary, I think we should remove any redundant URI information in the
"application/ipp", it seems to cause more confusion than what it is worth.

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]

---

From: Jay Martin <[email-masked]>
Date: Thu, 04 Jun 1998 20:03:02 -0400

Carl-Uno,

I'm a bit confused about who you're agreeing with here.

The text that you've quoted is from me, not Harry.

I read Harry's response to my posting as being in
mild disagreement, citing that the charter claimed
that IPP was supposed to be a generically usable
network printing protocol.

Are we to read that you've come to the position that
maybe IPP should be explicitly relegated for use over
HTTP, and not attempt to be transport-independent?
Or did I interpret your message incorrectly?

	...jay

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 4 Jun 1998 17:38:03 PDT

Jay,

Sorry, it seems that I misread what was written by you and what was written
by Harry.

If is was you who wrote about the misguided attempt to be fully transport
neutral, you are right, I DO agree with you. However, we will need to
tackle that problem when we try to do the SDP solution... just now I am
grping at straws (maybe another of those European proverbs that not
translate well to English) to get IPP V1.0 out the door.

Carl-Uno

Carl-Uno Manros