On the concern that a printer will have to decide whether or not to do =
both -
won't this be the case with any resolution other than just sticking wit=
h IPPv1
all around?
On the concern that the Host-Printer protocol will be constrained to th=
e
features of IPP - what set of features does the printer protocol need =
that IPP
does not need? Tom's idea was, if the IPP model is lacking, we need to =
identify
the requirements and extend it.
Harry Lewis - IBM Printing Systems
ipp-owner@pwg.org on 02/13/98 11:37:59 AM
Please respond to ipp-owner@pwg.org @ internet
To: jkm@underscore.com @ internet, Harry Lewis/Boulder/IBM@ibmus,
hastings@cp10.es.xerox.com @ internet, paulmo@microsoft.com @ internet
cc: ipp@pwg.org @ internet
Subject: RE: IPP> Re: Does the world need a robust host-to-device net
I disagree. If you have a client-to-server mapping protocol and then a
server-to-printer protocol, the gateway functions and semantics of the
job that the original user submitted would encounter no loss of
information and the gateway logic would be very straightforward. And
besides, I think there's going to be a very (repeat very) fine line
between the two anyway; the main difference probably being NOT using
HTTP as a transport.
Randy
-----Original Message-----
From: Paul Moore [SMTP:paulmo@microsoft.com]
Sent: Friday, February 13, 1998 9:41 AM
To: 'Tom Hastings'; Harry Lewis; jkm@underscore.com
Cc: ipp@pwg.org
Subject: RE: IPP> Re: Does the world need a robust
host-to-device network prin
Building a second protocol based on the model is the worst of
both worlds:-
- It is a separate completely non-interoperable protocol (being
based on the
same model means nothing in wire terms), would a printer do
both?
- It constrains the second protocol to only doing things that
IPP can do.
> -----Original Message-----
> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com]
> Sent: Thursday, February 12, 1998 5:23 PM
> To: Harry Lewis; jkm@underscore.com
> Cc: ipp@pwg.org; Paul Moore
> Subject: Re: IPP> Re: Does the world need a robust
host-to-device
> network prin
>
> I agree completely with Harry here. We need to build on IPP,
not start
> anew.
>
> In fact to further the discussion on defining such a "robust
> host-to-device"
> network printing protocol (probably NOT across firewalls) and
to test
> whether we can really build on IPP (as Harry and I advocate):
>
> People that are raising issues with IPP as the "robust
host-to-device
> network printing protocol when not going across firewalls",
> please indicate whether the problem is with the current IPP
Model
> document
> or the current IPP protocol document.
>
> For the problems with the Model document, they may be
resolvable by
> extending the Model, by, say, adding more Printer attributes
and maybe
> a Set-Printer-Attributes operation? And, of course,
notification.
>
> For problems that were with the protocol (mapping) document,
the PWG might
>
> develop a second IPP protocol document for use in the host to
printer
> connection whose semantics would be the same (extended) IPP
Model
> document.
> This second IPP protocol mapping document would be a PWG
standard, not an
> IETF standard, since the document deals with the host to
printer
> connection
> only (and not the Internet).
>
> NOTE that some printers would implement both IPP protocol
mappings, if
> they
> wanted to be used across the Internet and in the host to
printer
> connection.
> But with the same semantic model, such a dual implementation
would not be
> a big burden.
>
> Tom
>
>
>
> At 16:04 02/10/1998 PST, Harry Lewis wrote:
> >If we were to address a new, standard, host-to-device
printing protocol
> >
> >> Now if somebody wants to have a separate debate about
writing a really
> >> robust protocol for interfacing to printers (and I mean the
real
> hardware
> >> not some logical abstraction) then that will suit me fine.
Lets start a
> new
> >> track and call it, say, NLS (Not LPD and SNMP). This is
what I
> initially
> >> wanted to do but could not persuade enough people.
> >
> >in my opinion, it should be based on the set of attributes
defined for
> IPP
> >and the resulting device protocol should be as closely
correlated with
> IPP
> >as possible such that the mapping is very straight forward
and simple.
> >
> >Harry Lewis
> >
> >
=