Why are we even describing conformance w.r.t. notifications for IPP? Makes
sense, to me, for IPPFAX - a concrete application of IPP - but not
necessarily for IPP which is more of a tool than a "solution".
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"McDonald, Ira" <imcdonald@sharplabs.com>
Sent by: owner-ipp@pwg.org
04/16/2002 10:46 AM
To: "'Mike Bartman'" <bartman@process.com>, "'Carl'" <carl@manros.com>
cc: ipp@pwg.org
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by
April 15
Hi Mike,
You're confused. We are NOT making any notification method mandatory
for conforming IPP Clients.
Only IPP Clients which CLAIM to conform to IPP Notifications must
implement 'ippget'. Your implementation and Dennis Carney's
implementation are both (I hope) fully conforming to the IPP
Protocol (RFC 2910) and Model (RFC 2911). So you are 'IPP v1.1
conformant'.
OK?
Cheers,
- Ira McDonald
High North Inc
PS - Isn't the out-of-band email notification useful in your OpenVMS
environment? Certainly most of the UNIX/Linux print submission tools
(command line) let you set a flag for email notification.
-----Original Message-----
From: Mike Bartman [mailto:bartman@process.com]
Sent: Tuesday, April 16, 2002 11:19 AM
To: 'Carl'
Cc: ipp@pwg.org
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
Commen ts by April 15
I agree with Dennis' point, for what that's worth. I've pointed out once
or
twice in the past that not every IPP implementation is on a GUI PC, or
with
a user handy. Some, like ours (on OpenVMS), are part of the system's
printing software, and there are no users involved once a job is submitted
for printing. There is no reasonable way to implement any kind of
asynchronous notification about previous jobs, or need for a polled method
as part of the printing software. The OS's whole printing paradigm is
based
on the idea of a line printer, and once you've "printed" (i.e. sent) a
job,
it is *over*. The system forgets all about it, and moves on to the next
job. The printer symbionts don't even work at the job level...they work
with files, one at a time, and the part that we provide to handle the IPP
protocol only gets buffers one at a time from code that ships with the OS.
A
separate application that is used the way LPQ is on Unix might be good,
but
the actual printing client doesn't need, and can't support, any sort of
job
notification arrangement. Doing so would badly break the printing system.
We, like lots of others, would like to be able to say that we "support IPP
vX.X", but if the protocol includes mandatory things that aren't possible
in
our environment, we won't be able to do that. The fact that we support
every part of it that makes any sense in our environment, and can print
jobs
just fine using that portion, won't be good enough for some customers who
are buzzword oriented rather than capability oriented.
Notification methods are good, but making them mandatory...for the
client...seems pointless (as Dennis makes a good case for), as well as
counter-productive to the idea of getting wide-spread acceptance. For
servers, sure, but not for clients. Make it a part of the protocol, so
that
those that can benefit from it can use it, but to say that anyone who
can't
use a non-essential like notification isn't compliant is going too far.
IPP
1.0 mandated support for sending a file, but it made sending multiple-file
jobs optional. This made sense...you can't print at all if you can't at
least send a file, but sending multi-file jobs isn't necessary to getting
something printed. Only that which is essential to the basic task should
be
mandatory. Those frills that are nice, but not essential to the basic
task,
should be optional...either "should" or "may", but optional.
Thank you for listening to one implementer's opinion.
-- Mike Bartman
Process Software
bartman@process.com
> -----Original Message-----
> From: Carl [mailto:carl@manros.com]
> Sent: Tuesday, April 16, 2002 2:10 AM
> To: Dennis Carney; ipp@pwg.org
> Cc: 'Harry Lewis'; Hastings, Tom N; McDonald, Ira
> Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
> Commen ts by April 15
>
>
> Dennis,
>
> The whole idea about about IETF communication standards is to make
> interoperable implementations from a number of different vendors.
>
> To achieve interoperability you need to have something that
> is common among
> several implementations or you have no interoperability. You
> can implement
> additional optional stuff if you think that your customers have great
> interest in the options.
>
> BTW, nobody is twisting your arm if you happen to launch a
> product that
> isn't fully compatible with the standards, as long as you are
> not making
> such claims if they are not true. An common example is the
> implementation of
> HTTP. To my knowledge there is still no browser
> implementation that is fully
> conformant with the IETF HTTP spec, although Godzilla and
> Opera is getting
> close. Browser vendors instead have kept on adding private
> extensions rather
> than aiming for full alignment with the standard or claiming
> conformance
> with it. Not that I am recommending this behavious for IPP,
> but that is part
> of the real world out there.
>
> Carl-Uno
>
> Carl-Uno Manros
> 10701 S Eastern Ave #1117
> Henderson, NV 89052, USA
> Tel +1-702-617-9414
> Fax +1-702-617-9417
> Mob +1-310-251-7103
> Email carl@manros.com
>
> > -----Original Message-----
> > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf
> Of Dennis
> > Carney
> > Sent: Monday, April 15, 2002 6:53 PM
> > To: ipp@pwg.org
> > Cc: 'Harry Lewis'; Hastings, Tom N; McDonald, Ira
> > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
> > Commen ts by April 15
> >
> >
> >
> > So, let's say I have an IPP client that does not have a
> status GUI (job
> > submitter only); or an IPP client that implements status,
> but does it by
> > polling.
> >
> > Then I see the notifications drafts and I think that a nice
> > option to allow
> > my users is that if the printer supports e-mail notifications, I
> > will allow
> > them to give me their email address and I will register
> them for email
> > notifications.
> >
> > However, my client cannot claim to be an "IPP notifications
> compliant"
> > client because it hasn't implemented ippget. So to become
> compliant, I
> > must "implement"/"support" ippget, *even if* my client is
> not going to use
> > it? Hmmm, so since I'm not going to use it, I guess I
> don't have to test
> > my implementation very hard. But come to think of it, if
> I'm not going to
> > use it, no one can actually tell (by sniffing or any other
> method) whether
> > I have implemented it correctly (they can tell I didn't use
> it, but can't
> > tell whether my unused implementation code works or not). So I
> > guess I can
> > just claim I support ippget--no one can prove me wrong!
> >
> > This is what I'm trying to get at when I wonder what it
> means to force a
> > client to support something. Each client uses the interfaces
> > necessary for
> > it to get its job done. Forcing it to issue ippget calls then
> > simply throw
> > out the results, just so it can be compliant and have the
> buzzwords on its
> > marketing material, seems to be a mistake to me.
> >
> > Dennis Carney
> > IBM Printing Systems
> >
> >
> >
> >
> > "Hastings, Tom N"
> >
> > <hastings@cp10.es To:
> > "McDonald, Ira" <imcdonald@sharplabs.com>, Harry
> > .xerox.com>
> > Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N"
> > <hastings@cp10.es.xerox.com>
> > Sent by: cc: Dennis
> > Carney/Boulder/IBM@IBMUS, ipp@pwg.org
> > owner-ipp@pwg.org Subject: RE: IPP>
> > RE: Mandatory Delivery Method for Notifications - Commen
> > ts by April 15
> >
> >
> >
> > 04/15/02 12:26 PM
> >
> >
> >
> >
> >
> >
> >
> >
> > Harry,
> >
> > I agree with Ira. Furthermore, the advantage of having the client
> > conformance requirements (as well as the Printer conformance
> > requirements),
> > is that a client implementor knows that his/her conforming
> notifications
> > implementation will interoperate with any Printer that is also a
> > conforming
> > notifications implementation.
> >
> > BTW, the reason that we didn't have client conformance
> requirements in the
> > original Notifications and Subscriptions spec, is because
> we didn't have
> > agreement on any REQUIRED Delivery Method for the Printer
> when it supports
> > Notification. So now that we have agreement for the
> Printer, we can add
> > that requirement for the client (conditional on the client
> supporting
> > notifications at all).
> >
> > Tom
> >
> > -----Original Message-----
> > From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> > Sent: Monday, April 15, 2002 10:51
> > To: 'Harry Lewis'; Hastings, Tom N
> > Cc: Dennis Carney; ipp@pwg.org
> > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
> > Commen ts by April 15
> >
> >
> > Hi Harry,
> >
> > To prove interoperability in protocols, the IESG always requires
> > conformance requirements for both Client and Server (Printer, in
> > our case).
> >
> > But the requirement will be conditional:
> >
> > If an IPP Printer supports notifications, then it MUST support
> > the 'ippget' in-band delivery method.
> >
> > If an IPP Client supports notifications, then it MUST support
> > the 'ippget' in-band delivery method.
> >
> > OK?
> >
> > Cheers,
> > - Ira McDonald
> > High North Inc
> >
> > -----Original Message-----
> > From: Harry Lewis [mailto:harryl@us.ibm.com]
> > Sent: Thursday, April 11, 2002 4:04 PM
> > To: Hastings, Tom N
> > Cc: Dennis Carney; ipp@pwg.org
> > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
> > Commen ts by April 15
> >
> >
> > I support mandating IPPGET for IPP notification but I
> believe the mandate
> > should apply to the printer not the client.
> >
> > Architecturally, mandating support (for IPPGET) at the printer is
> > sufficient to support complete interoperability. It is
> overkill to mandate
> > both ends. For IPPFAX (a specific application of IPP) I
> agree we want to
> > lock down the specification for every node.
> >
> > Are you are saying that someone can build a client with
> (ex.) mailto
> > notification support (only)... but they just can't claim it
> is an IPP
> > client that supports notification? If someone chooses to do this, of
> > course they run the risk of reduced interoperability. That
> is a conscious
> > choice. The architecture and specifications still fully
> support complete
> > interoperability.
> > ----------------------------------------------
> > Harry Lewis
> > IBM Printing Systems
> > ----------------------------------------------
> >
> >
> >
> >
> > "Hastings, Tom N" <hastings@cp10.es.xerox.com>
> > Sent by: owner-ipp@pwg.org
> > 04/10/2002 06:08 PM
> >
> >
> > To: Dennis Carney/Boulder/IBM@IBMUS
> > cc: ipp@pwg.org
> > Subject: RE: IPP> RE: Mandatory Delivery Method for
> > Notifications - Commen ts
> > by April 15
> >
> >
> >
> > Dennis,
> >
> > Yes, I was adding to Carl-Uno's proposal, because in order to get
> > interoperability between a client and a Printer you need to have
> > conformance
> > requirements for both the client and Printer, not just the
> Printer. The
> > reason we left out client conformance in the Notification
> spec was because
> > we didn't have any Delivery Method REQUIRED for the Printer, if
> > Notifications were supported. But now the proposal is for the
> > Notification
> > spec to REQUIRE the Printer to support (implement) the
> IPPGET Delivery
> > Method, if the Printer supports Notification.
> >
> > However, I don't think that there is the problem that you
> think for adding
> > this client requirement. My entire statement was:
> >
> > 2. REQUIRE that a client support the IPPGET Delivery Method, if it
> > supports
> > IPP Notifications.
> >
> > The "if ..." doesn't require clients to support (implement)
> Notifications.
> > But if a client does support (implement) IPP Notifications,
> then it MUST
> > support (implement) IPPGET Delivery Method and MAY support
> (implement)
> > others. Then such a conforming client can interoperate
> with a conforming
> > Printer, including Notifications. None of these statement
> require the
> > client to actually *use* Notifications, if the user doesn't want to.
> >
> > OK?
> >
> > Tom
> >
> > -----Original Message-----
> > From: Dennis Carney [mailto:dcarney@us.ibm.com]
> > Sent: Wednesday, April 10, 2002 08:54
> > To: ipp@pwg.org
> > Cc: Hastings, Tom N
> > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
> > Commen ts by April 15
> >
> >
> >
> > Tom,
> >
> > I see a way in which your comments added a new wrinkle,
> although I may be
> > mistaken. I didn't get the impression in the previous
> messages that we
> > were discussing mandating that a *client* support IPPGET if
> it supports
> > any
> > notification mechanisms--I read Carl's "notification
> implementations" as
> > discussing IPP servers only.
> >
> > What does it mean that a client "support" a mandatory notification
> > mechanism? If the client has no interest in actually using that
> > mechanism,
> > it doesn't make sense to force the client to implement it
> anyway, then
> > just
> > not use it. Am I missing something?
> >
> > Dennis Carney
> > IBM Printing Systems
> >
> >
> >
> >
> >
> >
> > "Hastings, Tom N"
> >
> > <hastings@cp10.es To: Carl
> > <carl@manros.com>
> >
> > .xerox.com> cc: ipp@pwg.org
> >
> > Sent by: Subject:
> RE: IPP> RE:
> > Mandatory Delivery Method for Notifications - Commen
> ts by April 15
> > owner-ipp@pwg.org
> >
> >
> >
> >
> >
> > 04/09/02 07:32 PM
> >
> >
> >
> >
> >
> >
> >
> >
> > Carl-Uno,
> >
> > I support the proposal to REQUIRE a Notification Delivery
> Method so that
> > interoperability between a conforming client and a
> conforming Printer is
> > enhanced for Notifications.
> >
> > I also support the proposal to make IPPGET be that REQUIRED Delivery
> > Method
> > by changing the IPP Notifications and Subscriptions
> document (which is an
> > OPTIONAL IPP extension document) in the following ways:
> >
> > 1. REQUIRE that a Printer support the IPPGET Delivery Method, if the
> > Printer
> > supports IPP Notifications.
> >
> > 2. REQUIRE that a client support the IPPGET Delivery Method, if it
> > supports
> > IPP Notifications.
> >
> > 3. RFC 2910 already RECOMMENDs that a Printer support TLS,
> so saying the
> > same thing in the Notifications and Subscriptions document would be
> > redundant, but we could still do that.
> >
> > Compared to our other two Delivery Methods (MAILTO and
> INDP), the IPPGET
> > Delivery Method has the following advantages:
> >
> > a. it is the easiest Delivery Method to support
> > b. it is in-band so it doesn't create any additional
> firewall problems
> > c. it is also useful for LAN job submission (with no firewall)
> > d. it doesn't create any more administrative problems
> > e. it is REQUIRED for IPPFAX conformance.
> > f. and doesn't have any SPAM problems (since the job
> submitter is polling
> > and/or keeping a channel open for notification events).
> >
> >
> > The IPPGET spec also should be changed:
> >
> > 4. We should also change the IPPGET spec itself from its current
> > "RECOMMENDED" to "REQUIRED" as a Delivery Method for an IPP
> Printer to
> > support.
> >
> > Tom
> >
> > -----Original Message-----
> > From: Carl [mailto:carl@manros.com]
> > Sent: Saturday, March 30, 2002 13:30
> > To: Carl; ipp@pwg.org
> > Subject: IPP> RE: Mandatory Delivery Method for
> Notifications - Comments
> > by April 15
> >
> >
> > Resend, with spelling corrected etc. The earlier message
> slipped away
> > before
> > I had finished it.
> >
> > All,
> >
> > Ned Freed communicated in an earlier message to the IPP WG,
> that the IESG
> > found it unacceptable that we had not choosen ONE mandatory delivery
> > method
> > for notifications. They would also like to see that delivery method
> > mandate
> > the use of security.
> >
> > As those of you who were around about two years ago
> remember, we could not
> > reach agreement about mandating any of the delivery methods.
> >
> > However, in the meantime the members of the IPPFAX project
> in the Printer
> > Working Group has reached an agreement that they will
> require all IPPFAX
> > implementions to implement the 'ippget' delivery method, and it also
> > requires support for TLS security.
> >
> > Hence, I would like to put up the following strawman
> proposal to the IPP
> > WG
> > members to satisfy the IESG comments:
> >
> > 1) Change the main Notifiction document to require that
> 'ippget' delivery
> > MUST be included for all notification implementations, but
> any of the
> > other
> > two methods can also be implemented as an option.
> > <draft-ietf-ipp-not-spec-08.txt>
> >
> > 2) Put that rule also into the three delivery method
> documents, so it is
> > crystal clear what the rule is.
> > <draft-ietf-ipp-notify-get-06.txt>
> > <draft-ietf-ipp-notify-mailto-04.txt>
> > <draft-ietf-ipp-indp-method-06.txt>
> >
> > 3) Further, in the 'ippget' delivery document, we specify that TLS
> > security
> > MUST be supported.
> > <draft-ietf-ipp-notify-get-06.txt>
> >
> > If we can reach agreement on this, I will instruct the IPP editor to
> > implement these changes.
> >
> > I would like to get your reactions back on this proposal no
> later than
> > April
> > 15, 2002.
> >
> > Carl-Uno Manros
> > Chair of IETF IPP WG
> >
> > 10701 S Eastern Ave #1117
> > Henderson, NV 89052, USA
> > Tel +1-702-617-9414
> > Fax +1-702-617-9417
> > Mob +1-310-251-7103
> > Email carl@manros.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
This archive was generated by hypermail 2b29 : Tue Apr 16 2002 - 21:44:53 EDT